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(54) System and method for benchmarking asset characteristics 



(57) A computer based system that automatically 
gathers and analyzes relating to the procurement and 
utilization of a plurality of such assets, such as a fleet of 
industrial equipment, so as to maximize productivity and 
to reduce operating costs and administrative burdens 
by benchmarking relevant information. Benchmarking 
asset related data can be done on a company-wide or 



even industry-wide basis. The system is capable of 
benchmarking many different characteristics relating to 
assets. Industry-wide benchmarking can facilitate the 
determination of "best practices" for an entire industry. 
The system provides an analyst with a significant level 
of flexibility with regards to the types of data being 
benchmarked, the processing applied in the form a 
benchmark heuristic by the system. 
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Descripti n 

RELATED APPLICATIONS 

[0001] This application claims the benefit of U.S. Ap- 
plication Serial No. 09/441,289 filed November 16, 
1999, U.S. Provisional Application Serial No. 
60/166,042 filed November 17, 1999, U.S. Application 
Serial No. 09/503,671 filed February 14, 2000, U.S. Ap- 
plication Serial No. 09/504,000 filed February 14, 2000, 
U.S. Application Serial No. 09/504,343 filed February 
14, 2000, US Application Serial No. 09/653,735 filed 
September 1, 2000, U.S. Application Serial No. 
09/702,363 filed October 31 , 2000, and U.S. Application 
Serial No. 09/714,702 filed on November 16, 2000, the 
contents of which are all hereby incorporated in their en- 
tirety by reference. 

BACKGROUND OF THE INVENTION 

[0002] The present invention relates in general to sys- 
tems for benchmarking asset information. In particular, 
this invention relates to a computer based system for 
automatically gathering, analyzing, and delivering infor- 
mation relating to the maintenance of a plurality of such 
assets, such as a fleet of industrial equipment, so as to 
maximize pertinent information that can be bench- 
marked against other assets and industry wide data to 
facilitate increasingly informed purchasing decisions in 
the future. 

[0003] Many businesses operate a plurality of physi- 
cal assets to assist in the performance of the daily ac- 
tivities that are required to produce goods or services. 
For example, a typical manufacturer of goods often uses 
a fleet of industrial equipment, such as forklifts, convey- 
ors, machine tools, and the like, in its daily operations 
to facilitate the manufacture of goods for its customers. 
In a similar manner, a typical provider of services also 
often employs a plurality of assets, such as computers, 
communications equipment, photo imaging equipment, 
and the like, in its daily operations to facilitate the per- 
formance of services for its customers. Traditionally, 
businesses have purchased such assets for use in their 
facilities and have employed staff to operate and main- 
tain the assets in furtherance of the manufacture of 
goods or the performance of services. 
[0004] Regardless of the specific nature of the busi- 
ness, the operation of these assets has usually been 
considered to be somewhat ancillary to the core nature 
of the business. In other words, although the use of 
these assets is helpful (indeed, sometimes necessary) 
for the business to manufacture the goods or provide 
the services in a cost efficient manner, the ownership, 
operation, and maintenance of such assets is not, of it- 
self, a core function of the business. Consequently, the 
costs associated with the procurement and utilization of 
such assets have not been traditionally monitored or an- 
alyzed by the business in great detail. Rather, such 



costs have usually be n considered to be relatively fixed 
costs of doing business, and any manag ment of such 
assets has been performed, if at all, by relatively low 
level employees having little training or inclination to in- 
5 crease productivity and reduce costs. A lack of relevant 
asset-related data impeded attempts at benchmarking 
relevant asset characteristics in an attempt to determine 
"best practices" for an organization or industry. 
[0005] Optimization of productivity and minimization 
10 of costs are key considerations in the modem business 
environment. It would be desirable to capture and retain 
information relating to cost and utilization of an asset in 
order to facilitate better procurement and other business 
decisions in the future. Thus, it would be desirable to 
is provide a computer based system for automatically 
gathering, analyzing, and delivering information relating 
to the procurement and utilization of a plurality of such 
assets, such as a fleet of industrial equipment, to facil- 
itate a subsequent analysis of that information that in- 
20 dudes benchmarking data relevant to future business 
decisions, and the ability to estimate "best practices" on 
a company-wide or industry-wide basis. 
[0006] It would also be desirable to be able to provide 
different parties having an interest in the asset ready ac- 
25 cess to up-to-date real-time and historical access to the 
information associated with asset usage, maintenance, 
performance, and the like. For example, besides the 
business using the asset, there is often a third party 
maintenance organization that helps to maintain the as- 
30 set and a leasing company acting as the true asset own- 
er that leases the asset to the business. Because the 
leasing company lacks appropriate information con- 
cerning the asset, the leasing arrangement typically 
takes this lack of information into account as part of the 
35 lease transaction, often through a combination of both 
a fixed lease amount tied to the asset regardless of use, 
as well as a financial cushion for the benefit of the true 
asset owner to cover unforeseen problems associated 
with the asset including over-use and improper mainte- 
40 nance. 

[0007] It would also be desirable to be able to provide 
different parties having an interest in the asset ready ac- 
cess to up-to-date real-time and historical access to the 
information associated with asset usage, maintenance, 

45 performance, and the like. For example, besides the 
business using the asset, there is often a third party 
maintenance organization that helps to maintain the as- 
set and a leasing company acting as the true asset own- 
er that leases the asset to the business. Because the 

50 leasing company lacks appropriate information con- 
cerning the asset, the leasing arrangement typically 
takes this lack of information into account as part of the 
lease transaction, often through a combination of both 
a fixed lease amount tied to the asset regardless of use, 

55 as well as a financial cushion for the benefit of the true 
asset owner to cover unforeseen problems associated 
with the asset including ov r-use and improper mainte- 
nance. 
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[0008] In some situations it is known to provid a fixed 
flat rate rental contract that has a variable overtime pro- 
vision (e.g., an asset owner charges an asset user a flat 
rate plus an overtime charg in excess of a maximum 
usage level). However, a manual recordation of the ad- 
ditional time is required as opposed to automatic record- 
ing. 

[0009] In other situations it is known to provide billing 
tied to calendar usage (e.g., monthly). However, such 
usage does not take into account objective usage crite- 
ria such as actual hours of operation during a fixed time 
period. 

[0010] However, if the leasing company and the busi- 
ness both had ready access to the same information 
concerning the asset, the leasing company may be will- 
ing to share an increased portion of the financial risk/ 
reward associated with the asset's usage, maintenance, 
performance, and the like. With appropriate objective in- 
formation it may be possible to distribute a portion of the 
responsibility to other responsible third parties including 
the asset manufacturer or supplier, and asset mainte- 
nance organization. 

[001 1] It is known to record and store operational pa- 
rameters or fault codes associated with the asset, which 
may be transmitted using a communications network to 
a central location for the purpose of undertaking diag- 
nostics. It is also known to use handheld devices for the 
real-time sharing of information with a central system. 
The handheld device can access information from the 
central system such as the status of available inventory. 
The central system can also provide instructions to a 
user of the handheld device. Finally, it is known to use 
various electronic systems for monitoring inventory. 
[0012] However, if each of the entities involved with 
an asset had ready access to the same information con- 
cerning the asset, and the ability to update that informa- 
tion as well as related information associated with main- 
tenance of the asset on a real-time basis, the involved 
parties may be willing to share an increased portion of 
the financial risk/reward associated with the usage, 
maintenance, performance, or the like with respect to 
the asset. With appropriate objective information it may 
be possible to distribute a portion of the responsibility to 
other responsible third parties including the asset man- 
ufacturer or supplier, and asset maintenance organiza- 
tion. 

[0013] Benchmarking relevant characteristics or at- 
tributes relating to an asset can provide useful informa- 
tion for future decisions. However, the ability to bench- 
mark information in a meaningful way is often limited by 
a lack of data. For example, a small manufacturing fa- 
cility may not use or own enough forklifts to obtain sta- 
tistically significant data for benchmarking purposes. 
Even a larger organization may not own or use enough 
of a particular type or model of asset in order to obtain 
statistically significant benchmarking results. Thus, it 
would be desirable for a user of an asset benchmarking 
system to be able to benchmark asset data using the 



asset information of other companies or entities. One 
traditional obstacl to such a pooling of data is that com- 
panies do not want to share their identifiable business 
data with potential and actual competitors. Thus, it 

s would be desirable for a third-party to manage an asset 
benchmarking system to facilitate the pooling of data 
with which to benchmark. Furthermore, it would also be 
desirable if the asset benchmarking system could be 
configured to hide entity-specific data fields that would 

w reveal the identity ("organizationally identifiable infor- 
mation") of the data source ("source entity"), when al- 
lowing other non-source entities to benchmark with the 
benefit of the source entity's data. Such a configuration 
could maximize the benefits of information pooling with 

15 respect to benchmarking, while minimizing the factors 
that would make an entity reluctant to participate in such 
a pooling arrangement. 

SUMMARY OF THE INVENTION 

20 

[0014] This invention relates to a computer based 
system for automatically gathering, analyzing, and de- 
livering information relating to the procurement and uti- 
lization of a plurality of assets, such as a fleet of indus- 

25 trial equipment, to facilitate the ability to benchmark 
such information in a flexible and comprehensive man- 
ner, as desired by a user of the system. The system can 
facilitate the implementation of "best practices" for a 
company or other entity by providing a means for bench- 

30 marking asset information against internal or industry- 
wide information relating to similar and dissimilar as- 
sets. 

[0015] The system can benchmark information relat- 
ing to a particular asset against similar information for 

35 an entire group of similar or dissimilar assets. The sys- 
tem provides users with the ability to define the group 
of assets included in a particular analysis. Benchmark- 
ing can focus on past cost and utilization information and 
how such information relates to the proper use and 

40 maintenance of such assets. Benchmarking can also in- 
corporate a prospective view, such as when a particular 
type of model of an asset is being considered for pro- 
curement. 

[001 6] The system can be used to determine the total 
45 cost of owning an asset over the lifetime of an asset. 
The system can predict the annual costs relating to a 
particular asset. The system can calculate the average 
cost per hour relating to a particular asset. The system 
can receive, store, analyze, and benchmark character- 
50 istics or attributes of an asset such as: the type of asset 
(the type or model); the various functions of an asset; 
usage information, including the number of hours used 
per year; plant activity information, such as shifts used 
and hours available; maintenance information, including 
55 the type of maintenance performed and how often; the 
year the item was manufactured; and any other infor- 
mation relating to an asset that can be tracked, stored, 
and used for benchmarking against other assets. 
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[0017] The system can perform benchmarking which 
includes information not related to the entity performing 
the benchmarking analysis. The system can be used to 
pool together benchmarking information from non-relat- 
ed entities and organizations, including even competing 
entities, in order to provide a user with a volume of data 
no individual user of the system would otherwise have 
access to. The system can be configured to hide at- 
tributes or characteristics of asset information that 
would identify the source of the information. Such "hid- 
ing" can facilitate the willingness of entities to join in a 
multiple-entity information pooling arrangement. Entity 
identifiable information can be excluded while allowing 
other information to participate in the inter-entity infor- 
mation pool or group. 

[0018] Each of the assets is preferably provided with 
a data acquisition device for sensing and storing one or 
more operating characteristics associated therewith 
such as a fault code generated by the asset when there 
is a maintenance problem or when routine maintenance 
is required in accordance with predetermined criteria. 
That information can be transmitted through space to a 
receiver connected to a local controller for storing such 
information and for transmitting such information over 
the Internet to a remote analysis system. The remote 
analysis system automatically updates individual 
records associated with each of the assets with the in- 
formation received from the Internet. In response to 
such information, the remote analysis system automat- 
ically analyzes the newly provided information and gen- 
erates reports regarding scheduled maintenance, war- 
ranty coverage, and other management information. 
These reports can be transmitted back over the Internet 
to an administrative controller for review by one or more 
persons responsible for managerial review. Additionally 
or alternatively, the remote analysis system can auto- 
matically post such reports on a website and, thus, be 
made available to one or more of such persons upon 
request. 

[0019] Not only can the information be provided to an 
administrative controller, but in can also be provided to 
third parties such as maintenance organizations, asset 
manufacturers or suppliers, and leasing companies. By 
providing up-to-date real-time and historical information 
concerning the asset, such third parties are willing to 
share the risk of the asset's usage, maintenance, and 
performance through creative arrangements with the 
asset user. A maintenance organization, for example, 
may be willing to enter into a fixed maintenance contract 
when it has the ability to readily detect adverse mainte- 
nance trends regarding an asset and is given the ability 
to take pro-active steps to address problems before they 
become major. The cost-savings associated with such 
a pro-active approach by an expert may be shared to 
the benefit of the business and the maintenance organ- 
ization. Similarly, a leasing company that can reduc 
ownership risk through asset monitoring and appropri- 
ate asset utilization is more likely to agree to a hybrid 



minimum term payment and asset usage billing system 
or even a usage bas d billing system with no minimum 
payments. 

[0020] Various obj cts and advantages of this inven- 
5 tion will become apparent to those skilled in th art from 
the following detailed description of the preferred em- 
bodiment, when read in light of the accompanying draw- 
ings. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

[0021] Fig. 1 is a schematic block diagram of a prior 
art computer based system for tracking and managing 
a plurality of assets. 

15 [0022] Fig. 2 is a flow chart of a prior art method for 
tracking and managing assets in accordance with the 
prior art computer based system illustrated in Fig. 1. 
[0023] Fig. 3 is a schematic block diagram of a com- 
puter-based system for tracking and managing a plural- 

20 ity of assets in accordance with this invention. 

[0024] Figs. 4A through 4C are three portions, respec- 
tively, of a flow chart of a method for tracking and man- 
aging assets in accordance with the computer based 
system illustrated in Fig. 3. 

25 [0025] Fig. 5 illustrates the relationship of various par- 
ties to a database associated with an analysis controller. 
[0026] Fig. 6 is a flow chart of a subsystem illustrating 
the analysis of asset-related information to determine 
responsibility for asset utilization, and developing a 

30 lease relationship between an asset owner and an asset 
user based on asset utilization criteria. 
[0027] Fig. 7 is a flow chart illustrating the providing 
of maintenance to an asset in further detail. 
[0028] Fig. 8 is a flow chart illustrating what happens 

35 after a work order is generated based on maintenance 
approval. 

[0029] Fig. 9 is a flow chart illustrating the authoriza- 
tion subsystem 200. 

[0030] Fig. 10 illustrates the operation of data acqui- 
40 sition and analysis subsystem 300. 

[0031] Fig. 11 is a schematic block diagram illustrating 
a computer-based system for tracking and managing a 
plurality of assets that can also utilize the resulting in- 
formation for benchmarking purposes in a comprehen- 
ds sive and flexible manner. 

[0032] Fig. 12 is a schematic block diagram illustrat- 
ing how asset information for multiple entities can be 
used for benchmarking purposes. 
[0033] Fig. 13 is a flow chart illustrating the perform- 
so ance of benchmarking functionality 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

55 [0034] Referring now to the drawings, there is illus- 
trated in Fig. 1 a schematic block diagram of a prior art 
computer based system, indicated generally at 10, for 
tracking and managing a plurality of assets, several of 
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which are indicated generally at 11. The assets 11 are 
illustrated as being a plurality of pieces of movable in- 
dustrial equipment, such as a plurality of conventional 
forklifts or similar machinery, used in the manufacture 
of goods in a typical factory environment. However, the 
prior art method could be used to track and manage any 
type of asset 11, such as those described above, used 
in the manufacture of goods or the performance of serv- 
ices. The basic structure and operation of each of the 
forklifts 11 are well known in the art and, therefore, re- 
quire no discussion for a complete understanding of this 
invention. 

[0035] The prior art system 10 further included a re- 
mote analysis system, indicated generally at 12, for 
tracking and managing the assets 11. The remote anal- 
ysis system 12 was completely separate and apart from 
the assets 11 and included an analysis controller 13 hav- 
ing one or more input devices 1 4 and one or more output 
devices 1 5 connected thereto. The remote analysis sys- 
tem 12 could be embodied as any conventional elec- 
tronic controller, such as a microprocessor-based com- 
puter device. The input device 14 was embodied as a 
keyboard or other conventional mechanism for manual- 
ly inputting data in electronic form to the analysis con- 
troller 13 for processing in the manner described below. 
The output device 1 5 was embodied as a printer or other 
conventional mechanism for generating a hard copy of 
the management information generated by the analysis 
controller 13 in the manner described below. 
[0036] Referring now to Fig. 2, there is illustrated a 
flow chart, indicated generally at 20, of a prior art method 
for tracking and managing the assets 11 in accordance 
with the prior art computer based system 10 illustrated 
in Fig. 1. Throughout this discussion, reference will be 
made to a first person or entity that owns or operates 
the assets 11 that are being tracked and to a second 
person or entity that is responsible for tracking the man- 
agement information relating to such assets 11 . Notwith- 
standing this, it will be appreciated that a single person 
or entity may not only own and operate the assets 11, 
but also track the management information relating 
thereto. 

[0037] In an initial step 21 of the prior art method 20, 
a record was created for each individual asset 11 by the 
person or entity responsible for tracking such assets, 
such as one of the forklifts 11 illustrated in Fig. 1. This 
record was created electronically within the analysis 
controller 13 by means of the input device 14 and in- 
cluded a variety of information that was desired to be 
tracked for management purposes. First, the record in- 
cluded information that uniquely identified the particular 
asset 11 being tracked. Such identification information 
included, for example, data regarding the make, model, 
year, and serial number of the asset 11, plus any cus- 
tomer-assigned identification number. Second, the 
record included information that related to the operation- 
al characteristics of the particular asset 11 being 
tracked, such as the physical requirements or limitations 



of the asset 11 (mast height, load capacity, type of tires 
for the forklift 11 , for example), the type of fuel used, and 
the period of time or usage between the performance of 
periodic maintenance. Third, the record included infor- 

5 mation relating to the acquisition of the asset 11 by the 
owner or lessee thereof. Such acquisition information 
included, for example, the type and date of acquisition 
(purchase or lease, for example), the name of the owner 
or lessee, the location at which the asset 11 is used, the 

10 expected amount of usage of the asset 1 1 (one, two, or 
three shifts, for example), and the cost of the acquisition 
or lease. Furthermore, the record included an area for 
adding additional information or remarks as desired. 
[0038] In a second step 22 of the prior art method 20, 

15 it was determined whether a maintenance invoice had 
been received by the person or entity responsible for 
tracking the assets 11. Typically, a maintenance invoice 
was a written communication that was generated creat- 
ed by or at the request of the person or entity that owned 

20 or operated the assets 1 1 . The maintenance invoice was 
usually generated upon the occurrence of an event re- 
lating to the particular asset 1 1 and generally contained 
information regarding the status of one or more opera- 
tional characteristics of that asset 11. For example, after 

25 a particular forklift 11 had been operated by the person 
or entity that owned or operated the asset 11 for a par- 
ticular period of time, it would require the performance 
of some maintenance. This maintenance may, for ex- 
ample, have constituted routine preventative service as 

30 a result of the elapse of a predetermined period of time 
or usage. Alternatively, such maintenance may have 
constituted non-routine service, such as a repair of a 
mechanical breakdown. In either event, a maintenance 
invoice was generated as a result of the performance of 

35 that maintenance. The occurrence of other events relat- 
ed to the assets 11 could also result in the generation 
of maintenance invoices. In many cases, the mainte- 
nance was performed by a maintenance organization 
having specialized knowledge of asset 11 and its long- 

40 term care. 

[0039] Regardless of the nature of the event that 
caused them to be generated, the maintenance invoices 
were generated in hard copy form and contained therein 
certain information that was desired to be tracked for 

45 management purposes, such as the date and nature of 
the maintenance that was performed, the amount of us- 
age of the asset 11 as of the date of such maintenance, 
and the cost of such maintenance. To perform the sec- 
ond step 22 of the prior art method 20, the maintenance 
50 invoices were required to be physically delivered from 
the location where the assets 11 were being used or 
serviced to the location of the analysis controller 13 or 
to the location of the input device 14 of the analysis con- 
troller 13. By physically delivered, it is meant that the 
55 maintenance invoice was transmitted in a non-electron- 
ic, hard copy form (including, for example, by facsimile) 
from the person or entity that owned or operated the as- 
set 11 (and who performed, or had performed, the main- 
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tenance on the asset 11) to the person or entity respon- 
sible for tracking the assets 11 . 
[0040] As shown in Fig. 2, the prior art method 20 con- 
tinuously repeated step 22 until it was determined that 
a maintenance invoice had been received by the person 
or entity responsible for tracking the assets 11. When 
that occurred, the prior art method branched from the 
step 22 to a step 23, wherein the record contained in the 
analysis controller 13 relating to the particular asset 11 
was updated with the information contained in the main- 
tenance invoice. This step 23 was accomplished by uti- 
lizing the input device 1 4 to manually enter the informa- 
tion contained in the maintenance invoice into the record 
relating to the particular asset 11 contained in the anal- 
ysis controller 13. 

[0041] Based upon the updated information con- 
tained in the record of the asset 11 , the analysis control- 
ler 13 was programmed to perform a fourth step 24 of 
the prior art method 20, wherein it was determined 
whether a sufficient period of time or usage had elapsed 
as to trigger the performance of periodic routine main- 
tenance for that asset 11. Typically, such determination 
was made by determining the amount of the elapsed 
time or usage of the asset 11 (by comparing the most 
recent indication of the date or amount of usage of the 
asset 11 with the previous date or amount of usage con- 
tained in the record stored in the analysis controller 13), 
and by comparing such elapsed time or amount of us- 
age with a predetermined standard (also contained in 
the record of the asset 11 stored in the analysis control- 
ler 13). If it was determined that a sufficient amount of 
elapsed time or amount of usage had occurred, the 
method 20 branched from the step 24 to a step 25, 
wherein a hard copy maintenance report was generated 
by the output device 15. Then, in step 26 of the prior art 
method 20, the maintenance report generated in the 
step 25 was physically delivered from the person or en- 
tity responsible for tracking the asset 11 to the person 
or entity that owned or operated the asset 11 . The main- 
tenance report advised the person or entity that owned 
or operated the asset 1 1 that the time had arrived for the 
performance of periodic routine maintenance. 
[0042] Thereafter, the prior art method 20 entered a 
step 27, wherein it was determined whether a predeter- 
mined period of time had elapsed to generate a periodic 
management report covering some or all of the assets 
11 being tracked. Alternatively, if in step 24 of the prior 
art method 20, it was determined that a sufficient 
amount of elapsed time or amount of usage had not yet 
occurred, the method 20 branched directly from the step 
24 to the step 27. In either event, such management re- 
ports were typically generated on a monthly basis. Thus, 
if the end of the month had occurred, the prior art method 
20 branched from the step 27 to a step 28 wherein a 
hard copy management report was generated by the 
output device 1 5. Then, in step 29 of the prior art method 
20, the management report generated in the step 28 
was physically delivered from the person or entity re- 



sponsibl for tracking the asset 1 1 to the person or entity 
that own d or operated the asset 11 The management 
report advised the person or entity that owned or oper- 
ated the asset 1 1 of the status of some or all of th e assets 

5 11 that were being tracked, allowing various manage- 
ment oversight and decisions to be made at that time. 
Thereafter, the prior art method 20 returned from the 
step 29 to the step 22, wherein it was determined wheth- 
er a maintenance invoice had been created by or at the 

w request of the person or entity that owns or operates the 
assets 11 and was physically delivered to the person or 
entity responsible for tracking the assets 1 1 . Alternative- 
ly, if in step 27 of the prior art method 20, it was deter- 
mined that a predetermined period of time had not yet 

15 elapsed to generate a periodic management report cov- 
ering some or all of the assets 11 being tracked, then 
the method 20 returned directly from the step 27 to the 
step 22. 

[0043] Referring now to Fig. 3, there is illustrated 

20 schematic block diagram of a computer based system, 
indicated generally at 30, for tracking and managing a 
plurality of assets, indicated generally at 31, in accord- 
ance with this invention. As with the prior art system 10 
described above, the illustrated assets 31 are repre- 

25 sented as a plurality of pieces of movable industrial 
equipment, such as a plurality of conventional forklifts 
or similar machinery, used in the manufacture of goods 
in a factory environment. However, the method of this 
invention can be used to track and manage any type of 

30 asset 31, such as those described above, used in the 
manufacture of goods or the performance of services. 
[0044] As above, the basic structure and operation of 
each of the forklifts 31 are well known in the art, and, 
therefore, require no discussion for a complete under- 

35 standing of this invention. However, unlike the forklifts 
11 of the prior art system 10, a data acquisition device 
32 is provided on each of the forklifts 31 for sensing and 
storing one or more operating characteristics of the as- 
sociated forklift 31. The basic structure and operation of 

40 each of the data acquisition devices 32 are conventional 
in the art. For example, each of the data acquisition de- 
vices 31 may be embodied as an electronic processor 
or controller that can sense or be otherwise responsive 
to one or more operating conditions of the associated 

45 forklift 31. Each of the data acquisition devices 31 can 
be responsive to any desired operating conditions of the 
forklift 31 that might be considered important in making 
effective management decisions regarding the opera- 
tion of the forklift 31. Such desired operating conditions 

so can, for example, include the time duration of use (and 
non-use), distances traveled, the extent of fork usage, 
the nature of hydraulic system utilization, and the like. 
More typically for industrial assets, the most important 
criteria is time duration of use. The sensed operating 

55 conditions of the forklifts 31 are preferably stored at least 
temporarily in a memory of the data acquisition device 
32 for subsequent communication to a remote analysis 
system, indicated generally at 50, for analysis in the 
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manner described in detail below. Thus, the data acqui- 
sition devices 32 sense and store the desired operating 
conditions for each of the forklifts 31 during use. 
[0045] Each of the forklifts 31 is further provided with 
a transmitter 33 or other communications system for 
transmitting the acquired data from the data acquisition 
device 32 to the remote analysis system 50 for analysis. 
Each of the transmitters 33 may be embodied as any 
conventional device for transmitting the acquired data 
to the remote analysis system 50, such as a hard-wired 
communications interface. However, as is well known, 
each of the forklifts 31 is a movable vehicle that is ca- 
pable of traveling extensively throughout the particular 
environment in which it is used. To facilitate the trans- 
mission of the acquired data, therefore, the transmitter 
33 is preferably embodied as a wireless communica- 
tions system, such as represented by an antenna 34. 
The transmitters 33 and the wireless communications 
systems 34 can be embodied as conventional radio fre- 
quency transmitters provided on each of the forklifts 31 
that transmit electromagnetic signals. However, other 
well known forms of wireless communication, such as 
those utilizing light or sound, may be used in lieu of a 
radio frequency transmitter. 

[0046] The wireless communications systems 34 are 
adapted to transmit signals that are representative of the 
sensed operating conditions of the forklifts 31 through 
space to a receiver 35. In contrast to the forklifts 31 that 
can travel extensively throughout the environment in 
which they are operated, the receiver 35 is preferably 
provided at a fixed location within that environment. If 
desired, a plurality of such receivers 35 may be provided 
at different locations within the environment in which the 
forklifts 31 are operated. As the forklifts 31 move about 
the environment during use, they will occasionally pass 
by or near the receiver 35. When this occurs, the receiv- 
er 35 receives the data transmitted from the respective 
data acquisition units 32. The receiver 35 is also con- 
ventional in the art. 

[0047] Preferably, the data acquisition units 32 and 
the receivers 35 are in bi-directional communication with 
one another. One advantage of such bi-directional com- 
munication is that the data acquisition unit 32 can send 
out a query signal on a predetermined basis to be re- 
ceived by the receiver 35 when the two units 32 and 35 
are sufficiently close to communicate reliably with one 
another. Thus, when the data acquisition unit 32 con- 
tacts the receiver 35, the receiver 35 can send a first 
signal back to the data acquisition unit 32 to instruct it 
to begin transmitting the acquired data. At the comple- 
tion of the data transfer, the receiver 35 can send a sec- 
ond signal back to the data acquisition unit 32 to ac- 
knowledge the receipt of the transmitted data. A con- 
ventional error checking algorithm can be used to con- 
firm the accuracy and completeness of the transmitted 
data and, if necessary, request a retransmission thereof. 
[0048] Another advantage of such bi-directional com- 
munication is that data in the form of new commands, 



program updates, instructions, and the like can be sent 
to the data acquisition units 32 from the receiver 35. In 
some instances, such as when a data acquisition unit 
32 is in generally continuous communication with a re- 

5 ceiver 35, a user of the forklift 31 can be prompt d to 
provide certain information for transmission to the re- 
ceiver 35 for further analysis. 
[0049] The receiver 35 is connected to a local control- 
ler 36. The local controller 36 is also, of itself, conven- 

'0 tional in the art and may be embodied as an electronic 
controller that is adapted to receive and store at least 
temporarily the data from each of the receivers 35. Al- 
ternatively, if the assets 31 are fixed in position, such as 
in the case of a plurality of stationary machines used in 

'5 a manufacturing environment, the receiver 35 or receiv- 
ers 35 may be provided on movable structures that 
move about the environment to receive the information 
transmitted therefrom. In either event, it is desirable that 
the local controller 36 acknowledge receipt of the infor- 

20 mation transmitted from the data acquisition devices 32, 
allowing the data acquisition devices 32 to delete the 
transmitted information and begin storing newly ac- 
quired information. A combined system including the da- 
ta acquisition device 32, the transmitter 33, the wireless 

25 communications system 34, the receiver 35, and soft- 
ware for operating the local controller 36 to gather and 
report data is commercially available, such as from I.D. 
Systems, Inc. of Hackensack, New Jersey or Requip 
(formerly SXI). 

30 [0050] In a preferred embodiment, the various ele- 
ments located in an asset 31 are hardwired into the elec- 
trical system of the asset to minimize the possibility of 
undesirable failure or tampering. 
[0051] Thus, after the forklifts 31 have been operated 

35 for a period of time, the local controller 36 will have gath- 
ered and stored therein a certain amount of information 
regarding the individual operating characteristics for 
each of the forklifts 31 . The local controller 36 is pro- 
grammed to periodically transmit the information stored 

to therein to the remote analysis system 50 for analysis. 
This can be accomplished by providing the local con- 
troller 36 with a conventional modem 37 or other com- 
munications device that can convert the stored informa- 
tion into a format that is compatible for transmission 

is through an electronic communications network, such as 
the internet 40. As is well known, the Internet 40 is a 
digital electronic communications network that connects 
computer networks and organizational computer facili- 
ties around the world. Access to the Internet 40 can be 

50 easily obtained in most locations through the local tele- 
phone lines or by similar means. 
[0052] The system 30 of this invention may be used 
to track and manage a plurality of assets 31 located at 
any desired physical location. Additionally, the system 

55 30 of this invention may be used to track and manage 
assets 31 located at a plurality of different physical lo- 
cations, as suggested by the dotted lines in Fig. 3. Each 
different physical location can be provided with one or 
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more receiver 35, a local controller 36, and a modem 37 
to connect the system 30 to the Internet 40. 
[0053] As mentioned above, the sensed operating 
conditions of the forklifts 31 are intended to be transmit- 
ted to the remote analysis system 50 for analysis. Re- 
ferring again to Fig. 3, it can be seen that the remote 
analysis system 50 includes an analysis controller 51 
that is connected to communicate through the internet 
40 by means of a modem 52 or similar communications 
device. If desired, a communications server 51 a may be 
connected between the analysis controller 51 and the 
modem 52. The communications server 51 a is provided 
to selectively receive and organize the information from 
each of the local controllers 36 for delivery to the anal- 
ysis controller 51 . The analysis controller 51 can be em- 
bodied as any conventional electronic controller that is 
capable of receiving the sensed operating conditions of 
the forklifts 31 and for processing that information in a 
desired manner described in detail below. Ideally, the 
sensed operating conditions of the forklifts 31 are used 
to automatically generate and analyze management re- 
ports relating to the procurement and utilization of a plu- 
rality of the forklifts 31 to maximize productivity and to 
reduce operating costs and administrative burdens. An 
input device 53 and an output device 54, both of which 
are conventional in the art, may be connected to the 
analysis controller 51. 

[0054] As also shown in Fig. 3, one or more adminis- 
trative controllers 55 (only one is illustrated) can be con- 
nected to the internet 40 through respective modems 56 
or similar communications devices. Each of the admin- 
istrative controllers 55 can also be embodied as any 
conventional electronic controller that can request and 
receive information from the remote analysis system 50 
through the Internet 40. In a manner that is described in 
detail below, the administrative controllers 55 are pro- 
vided to request and receive the management informa- 
tion generated by the remote analysis system 50. If de- 
sired, the local controller 36 can also function as an ad- 
ministrative controller 55, although such is not neces- 
sary. An input device 57 and an output device 58, both 
of which are conventional in the art, may be connected 
to the administrative controller 55. 
[0055] Referring now to Figs. 4A through 4C, there is 
illustrated a flow chart, indicated generally at 60, of a 
method for tracking and managing the assets 31 in ac- 
cordance with this invention using the computer based 
system 30 illustrated in Fig. 3. Throughout this discus- 
sion also, reference will be made to a first person or en- 
tity that owns or operates the assets 31 that are being 
tracked and to a second person or entity that is respon- 
sible for tracking information relating to such assets 31 . 
As above, it will be appreciated that a single person or 
entity may not only own and operate the assets 31 , but 
also track the information relating thereto. 
[0056] In an initial step 61 of the method 60, a record 
is created for each individual asset 31 by the person or 
entity responsible for tracking such assets, such as one 



of the forklifts 31 illustrated in Fig. 3. The record can be 
created electronically within the analysis controller 51 
by means of the input device 53 and can include a va- 
riety of information that is desired to be tracked for man- 

5 agement purposes, including all of the information de- 
scribed above in connection with the forklifts 11 and the 
analysis controller 13. Additionally, the record can fur- 
ther include information regarding the nature and time 
duration of a warranty provided by the manufacturer or 

10 supplier of the assets 31. Such warranty information can 
be used in the manner described in further detail below 
to automatically determine whether the responsibility for 
the maintenance being performed on the asset 31, ei- 
ther in whole or in part, should rest with the manufacturer 

15 or the supplier of the asset 31 or with the owner or user 
of the asset 31. 

[0057] In a second step 62 of the method 60, it is de- 
termined whether a maintenance invoice has been re- 
ceived by the person or entity responsible for tracking 

20 the assets 31 . Such maintenance invoices can be gen- 
erated and delivered in the same manner as described 
above. If it is determined that a maintenance invoice has 
been received by the person or entity responsible for 
tracking the assets 31, the method branches from the 

25 step 62 to a step 63, wherein the record contained in the 
analysis controller 51 relating to the particular asset 31 
is updated with the information contained in the mainte- 
nance invoice in the same manner as described above. 
Next, the method enters a step 64 wherein the record 

30 contained in the analysis controller 51 relating to the par- 
ticular asset 31 is updated with information from the in- 
ternet 40. Alternatively, if it is determined that a mainte- 
nance invoice has not been received by the person or 
entity responsible for tracking the assets 31 , the method 

35 branches directly from the step 62 to the step 64. 

[0058] As discussed above, the local controller 36 will 
have gathered and stored therein a certain amount of 
information regarding the individual operating charac- 
teristics for each of the forklifts 31. The local controller 

■*o 37 is programmed to periodically transmit the informa- 
tion stored therein to the remote analysis system 50 for 
analysis. The analysis controller 51 can include a mem- 
ory circuit for storing this information from the local con- 
troller 36. The transmission of the information from the 

45 local controller 36 to the analysis controller 51 can be 
performed in real time, upon occurrence of predeter- 
mined events (such as the gathering of a predetermined 
amount of information), or at predetermined time inter- 
vals. In any event, the record contained in the analysis 

so controller 51 is automatically updated with the latest in- 
formation regarding the status of the asset 31 , without 
any human intervention. 

[0059] Based upon the updated information con- 
tained in the record of the asset 31 , the analysis con- 
55 troller 51 next determines whether a sufficient period of 
time or usage has elapsed as to trigger the performance 
of periodic routine maintenance for that asset 31. This 
determination can be made in the same manner as de- 
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scribed above in connection with 24 of the prior art meth- 
od 20. If it is determined that a sufficient amount of 
elapsed time or amount of usage had occurred, the 
method 60 branches from the step 65 to a step 66, 
wherein an electronic maintenance report is generated. 
If desired, a hard copy of the maintenance report can 
also be generated by an output device 54 connected to 
the analysis controller 51 . Then, in step 67 of the method 
60, the electronic maintenance report generated in the 
step 66 is delivered from the person or entity responsible 
for tracking the asset 31 to the person or entity that owns 
or operates the asset 31 through the Internet 40. As 
above, the maintenance report can advise the person 
or entity that owns or operates the asset 31 that the time 
has arrived for the performance of periodic routine main- 
tenance. Moreover, if a specific fault code has been gen- 
erated, that can be provided as well. Alternatively, the 
maintenance report 55 can be delivered to a specialized 
maintenance organization responsible for maintenance 
of the assets 31 . The electronic maintenance report can, 
for example, be delivered through the Internet 40 to one 
or more of the administrative controllers 55 as desired. 
Alternatively, or additionally, the electronic maintenance 
report can be delivered through the Internet 40 to one 
or more of the local controllers 36. Also, in step 68 of 
the method 60, the electronic maintenance report gen- 
erated in the step 66 is posted on a website maintained 
on the Internet 40. The website may be maintained ei- 
ther by the person or entity responsible for tracking the 
asset 3 1 or by the person or entity that owns or operates 
the asset 31 through the Internet 40. As opposed to the 
direct electronic delivery of the maintenance report to a 
particular person or group of persons contemplated in 
the step 67, the step 68 contemplates that the mainte- 
nance report is made available to such person or group 
of persons at their request over the Internet 40. 
[0060] Thereafter, the method 60 enters a step 69, 
wherein it is determined whether any maintenance that 
has been performed on the asset 31 occurred within the 
warranty period provided by the manufacturer or suppli- 
er. Alternatively, if in the step 65 of the method 60, it was 
determined that a sufficient amount of elapsed time or 
amount of usage had not yet occurred, the method 60 
branches directly from the step 65 to the step 69. In ei- 
ther event, this determination can be made by compar- 
ing the date of service or amount of usage of the asset 
31 with the warranty information contained in the record 
for that asset 31 contained in the analysis controller 51. 
If it is determined that service on the asset 31 occurred 
within the warranty period, the method 60 branches from 
the step 69 to a step 70, wherein an electronic warranty 
report is generated. If desired, a hard copy of the war- 
ranty report can also be generated by the output device 
54 connected to the analysis controller 51 . Then, in step 
71 of the method 60, the electronic warranty report gen- 
erated in the step 70 is delivered from the person or en- 
tity responsible for tracking the asset 31 to the person 
or entity that owns or operates the asset 31 through the 



Internet 40. As above, the warranty report can advise 
the person or entity that owns or operates the asset 31 
that th service performed on the asset 31 should be 
paid for by the manufacturer or supplier of the asset 31 . 

5 The electronic warranty report can, for example, be de- 
livered through the Internet 40 to one or more of the ad- 
ministrative controllers 55 as desired. Alternatively, or 
additionally, the electronic warranty report can be deliv- 
ered through the Internet 40 to one or more of the local 

10 controllers 36. Also, in step 72 of the method 60, the 
electronic warranty report generated in the step 70 is 
posted on a website maintained on the Internet 40. The 
website may be maintained either by the person or entity 
responsible for tracking the asset 31 or by the person 

'5 or entity that owns or operates the asset 31 through the 
Internet 40. As opposed to the direct electronic delivery 
of the warranty report to a particular person or group of 
persons contemplated in the step 71, the step 72 con- 
templates that the warranty report is made available to 

20 such person or group of persons at their request over 
the Internet 40. 

[0061] Thereafter, the method 60 enters a step 73, 
wherein it is determined whether a predetermined peri- 
od of time has elapsed to generate a periodic manage- 

25 ment report covering some or all of the assets 31 being 
tracked. Alternatively, if in step 69 of the method 60, it 
was determined that a sufficient amount of elapsed time 
or amount of usage had not yet occurred, the method 
60 branches directly from the step 69 to the step 73. In 

30 either event, such management reports are typically 
generated on a monthly basis. Thus, if the end of the 
month has occurred, the method 60 branches from the 
step 73 to a step 74, wherein an electronic management 
report is generated. If desired, a hard copy of the man- 

35 agement report can also be generated by the output de- 
vice 54 connected to the analysis controller 51. Then, 
in step 75 of the method 60, the electronic management 
report generated in the step 74 is delivered from the per- 
son or entity responsible for tracking the asset 31 to the 

40 person or entity that owns or operates the asset 31 
through the Internet 40. As above, the management re- 
port can advise the person or entity that owns or oper- 
ates the asset 31 of the same information as the man- 
agement reports discussed above. The electronic man- 

45 agement report can, for example, be delivered through 
the Internet 40 to one or more of the administrative con- 
trollers 55 as desired. Alternatively, or additionally, the 
electronic management report can be delivered through 
the Internet 40 to one or more of the local controllers 36. 

50 Also, in step 76 of the method 60, the electronic warranty 
report generated in the step 74 is posted on a website 
maintained on the Internet 40. The website may be 
maintained either by the person or entity responsible for 
tracking the asset 31 or by the person or entity that owns 

55 or operates the asset 31 through the Internet 40. As op- 
posed to the direct electronic delivery of the manage- 
ment report to a particular person or group of persons 
contemplated in the step 75, the step 76 contemplates 
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that the management report is made available to such 
person or group of persons at their request over the In- 
ternet. 

[0062] Fig. 4C demonstrates an additional functional 
aspect of method 60 using the inventiv system. In ad- 
dition to determining whether a maintenance invoice 
has been received, if scheduled maintenance has been 
performed, and determining the party responsibility for 
certain maintenance activities, it is possible to poll asset 
data points at point 76 from an analysis controller data- 
base 78 associated with one or more discrete analysis 
controllers 51 that may be associated with one or more 
businesses. A plurality of databases 78 is shown. One 
or more separate databases may be combined to form 
a logical database 78. When a maintenance organiza- 
tion has access to various asset fleets of the same type 
or make of equipment, it may be beneficial to analyze 
the relevant information using a larger available knowl- 
edgebase of information to analyze appropriate trends. 
By analyzing the data points, certain maintenance 
trends can be analyzed and problems can be anticipat- 
ed before they affect asset utilization. For example, if it 
turns out that asset 31 has a tendency to need new bat- 
teries after a certain period of usage; the need for such 
batteries can be anticipated and stocked on site when 
appropriate to facilitate maintenance. As shown in Fig. 
4C, once the various trends have been analyzed for as- 
sets 31 , at decision point 80 it is determined whether 
preventative maintenance is required. If it is required, 
the maintenance is performed as shown at point 82 and 
the information is stored in database 78. The asset data 
points are then analyzed again until it is determined that 
no further preventative maintenance is required. Then 
the system terminates at point 84. Thus, figures 4A 
through 4C illustrate the use of critical information from 
assets 31 to perform maintenance and to provide a 
methodology for providing access to information by var- 
ious third parties. 

[0063] There are a number of significant advantages 
to having appropriate access to and the ability to ana- 
lyze data associated with an asset 31 and the interaction 
of various parties with that asset. Fig. 5 illustrates the 
beneficial interrelationships that promote efficiency by 
having the various parties associated in some way with 
an asset 31 in one or two-way communication with anal- 
ysis controller 51 either by way of administrative con- 
troller 55, reports 71 or 75, web site postings electronic 
mail, or the like. As illustrated , a maintenance organiza- 
tion 86, an asset manufacturer or supplier 88, asset us- 
er/business 90, and asset owner/leasing company 92 
all at least provide information to analysis controller da- 
tabase 78 of analysis controller 51. Both an individual 
user 85 and the asset 31 itself also provide data as il- 
lustrated in the figure and discussed herein. Therefore, 
at the very least each party is required to contribute per- 
tinent information concerning its interaction with an as- 
set 31 to database 78 of asset controller 51 , where the 
information is available for further consideration and 



analysis. 

[0064] As already discussed above, asset 31 pro- 
vides usag and performance data that is stored in asset 
controller 51 according to certain predetermined criteria 

s important for that asset including such things as ass t 
location, model, age, usage, and maintenance status. 
Once relevant data is collected, it is possible to analyze 
utilization of a specific asset 31. It is also possible to 
analyze a class of assets 31 using one or more types of 

10 available data. From such an analysis, best mode prac- 
tices can be developed with respect to asset utilization 
including preventative maintenance and a determina- 
tion of the extent of optimum asset use. More specifical- 
ly, for example, a business 90 may decide to standardize 

15 its fleet of assets, replace specific assets that have dem- 
onstrated unreliability, and either upsize or downsize a 
fleet to maximize safe asset utilization. 
[0065] As discussed in greater detail with respect to 
Fig. 9 below, utilization of asset 31 by an individual user 

20 85 is also tracked. A review of the available data can 
also provide detailed information on the interaction of a 
business 90 or individual users 85 with assets 31 as op- 
posed to other businesses or users. From such an anal- 
ysis it is possible to consider training issues, certifica- 

25 tion, and issues related to particular individuals, whose 
actions can have significantly influence asset utilization. 
[0066] The role of other vendors such as part distrib- 
utors, an example of another vendor 93, and mainte- 
nance organizations 86 can be compared with respect 

30 to other parties in similar roles or historical data to de- 
termine their effectiveness. While business 90 may pro- 
vide its own maintenance of assets 31 , a separate main- 
tenance organization 86 is in the illustrated embodi- 
ment. 

35 [0067] A vendor may be penalized or rewarded de- 
pending on the results of its activities, providing in- 
creased incentives to promote efficiencies. With respect 
to asset manufacturers or suppliers 88, it is possible to 
compare assets provided by different parties 88 to de- 

40 termine how well their assets perform in practice. Thus, 
warranty issues, maintenance costs, lost operation 
time, and the like can be determined from an analysis 
of asset information overtime or involving different man- 
ufacturers to provide guidance on how assets 31 from 

« a particular manufacturer perform in different environ- 
ments and as compared to competing assets of other 
manufacturers or suppliers in that environment. 
[0068] More specifically, for an asset manufacturer or 
supplier 88, warranty information as shown by steps 70 

50 through 72 of Fig. 4B is of particular interest. While it 
may not be appropriate for a supplier 88 to be able to 
alter information in database 78, the ability to quickly 
and accurately collect information concerning warranty 
obligations and the like is of particular benefit to all of 

55 the parties. For example, warranty issues may be 
caught more quickly, ultimately reducing asset cost and 
operation while simultaneously promoting asset up 
time. 
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[0069] The advantages of an asset owner 92 having 
at least one and possibly two-way access to the real- 
time and historical information stored in analysis con- 
troller database 78 as well as the ability to communicate 
with supplier 88, maintenance 86, and business 90, is 
illustrated in subsystem 98 illustrated in Fig. 6. It is as- 
sumed for the discussion that follows that the owner of 
the asset 31 is a separate asset owner 92 such as a 
leasing company, as opposed to business 90 itself, al- 
though this is not a requirement of the invention, sub- 
system 98 is often activated by the asset owner 92 using 
data from database 78, but typically utilizing its own 
lease administration and billing systems. In many cases 
it is also using its own fleet analysis and management 
systems, which are typically aggregating information 
from a number of different fleets associated with a plu- 
rality of businesses 90. These various systems, one or 
more of which may be used independently or in concert, 
are collectively shown at point 99. As noted above, web- 
site access, generated reports, analysis controllers 51, 
and administrative controllers 55 provide exemplary ac- 
cess points for pulling asset information from system 30. 
[0070] An asset owner 92 and an asset user such as 
business 90 share the common interest in maximizing 
efficiency by taking into account such variables as asset 
usage and asset costs. The more information that is 
available, the more likely that efficiency is maximized. 
In traditional leasing relationships involving non-fixed or 
movable assets such as forklifts where minimal asset 
utilization information is available, the burden of deter- 
mining the point of maximum efficiency typically rests 
with business 90, since it has control over the asset. 
Therefore, a leasing company 92 typically enters into a 
lease arrangement where a fixed lease amount is paid 
in periodic payments by business 90 over the life of the 
lease. At best, only minor flexibilities are provided. 
When leasing company 92 regains control of an asset 
31 at the end of the lease term, there is uncertainty con- 
cerning the condition of the asset. This uncertainty also 
typically rests with business 90 in the form of a financial 
cushion incorporated into the leasing relationship. 
[0071] However, such uncertainty is minimized in the 
present invention. As shown at point 100, asset owner 
92 is able to analyze the various desired objectively gen- 
erated asset data points associated with an asset 31. 
As noted above, these data points can include the time 
of asset usage within a fixed time period, distance 
traveled, and certain performance parameters associ- 
ated with the particular asset (e.g., hydraulic system us- 
age or fork usage for fork lifts). As noted above, in prac- 
tice, for industrial assets the time of use is the most im- 
portant single data point. Then, as shown at point 102, 
asset owner 92 may analyze maintenance considera- 
tions. For example, a major routine overhaul as com- 
pared to a system failure can be analyzed. Then at point 
104, the asset owner 92 can compare the raw data from 
the asset with maintenance conducted during the same 
time period. By comparing the raw data with mainte- 



nance considerations, the owner is able to analyze the 
asset utilization under the control of business 90 if main- 
tenance organization 86 and supplier 88 are different 
third parties. For example, the asset own r 92 can de- 

5 termine that an asset 31 has been used very little during 
the time period, even allowing for maintenance. Alter- 
natively, the owner may determine that the asset is be- 
ing used continuously when not undergoing mainte- 
nance, possibly suggesting that additional assets may 

10 be appropriate to reduce overall maintenance stress on 
the pre-existing asset. 

[0072] Additional information can be analyzed by the 
asset owner as shown at decision point 1 06. Typically, 
the information includes data associated with other par- 

15 ties having access to database 78. As shown at point 
108, for example, the asset owner 92 can evaluate the 
maintenance relationship with maintenance organiza- 
tion 86. If the relationship has been very positive, an ap- 
propriate incentive may be provided to the organization 

20 in the form of shared cost savings. Alternatively, if the 
relationship has been negative, an appropriate penalty 
may also be implemented. The same considerations are 
available if business 90 acts as its own maintenance or- 
ganization 86. 

25 [0073] Similarly, the asset owner 92 may evaluate its 
relationship with the asset supplier 88 as shown at point 
110. The information may affect asset payments from 
the owner to the supplier or the future relationship of the 
parties. 

30 [0074] A further evaluation, shown at point 111, may 
include an analysis of individual users 85 themselves 
associated with a specific business 90 and their inter- 
action with particular assets 31 or classes of assets, and 
such things as training level, certification, accident 

35 rates, and the like as discussed with respect to Fig. 9 
and authentication subsystem 200 below. 
[0075] One of the key advantages of the present in- 
vention is the ability to take data concerning any asset 
31 and the interaction with that asset by any party, in- 

40 eluding user 85, maintenance organization 86, asset 
manufacturer or supplier 86, business 90, asset owner 
92, or other parties/vendors 93. Moreover, groups of as- 
sets may be combined. Thus, it is possible to analyze 
data to identify the cost of owning or using any asset 31 

is and the productivity of that asset. Moreover, based on 
an adequately large statistical universe of data it is pos- 
sible to benchmark asset utilization and cost against 
others in similar circumstances to identify best practic- 
es. Thus, it is possible to efficiency can be maximized 

so while simultaneously minimizing unwanted waste by 
identifying time and cost saving opportunities. It is also 
possible to determine those parties providing best prac- 
tice services with respect to asset utilization (e.g., main- 
tenance) so that their services can be expanded and ap- 

55 propriate recognition given fortheir efforts. Alternatively, 
it is possible to identify parties providing unacceptable 
services so that appropriate remedial action may be tak- 
en (e.g., a user 85 has inadequate training to properly 
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use an asset so additional training needs to be provid- 
ed). The ability of the system 30 to perform benchmark- 
ing is described in greater detail below. 
[0076] In practice, the present invention provides a 
business 90 with a report screen showing information 
regarding the fleet associated with that business. Busi- 
ness 90 compares its current fleet information with its 
own historical information or pertinent information from 
unnamed companies in the same general industry. A 
side-by-side comparison will be provided, thereby pro- 
viding a business 90 or the asset owner 92 with guid- 
ance on how to improve fleet utilization using the best 
practices comparison. 

[0077] These various advantages are applicable even 
if asset owner 92 and business 90 are the same entity. 
However, more typically with industrial equipment, asset 
owner 92 is different than asset user 90, where the two 
parties have entered into a lessor/lessee relationship. 
In such a case, the information in database 78 may be 
used to mutually maximize the relationship between the 
asset owner 92 and the business 90. With appropriate 
safeguards asset owner 92 may be willing to share in a 
greater portion of the risk associated with the utilization 
of asset 31 in determining a lease rate based on an anal- 
ysis of each user fleet or individual asset as shown at 
point 112. Most significantly, rather than entering into a 
traditional fixed lease amount as noted above, asset 
owner 92 may be willing to enter into a hybrid lease ar- 
rangement wherein the lease charge may be a combi- 
nation of one or more of the following elements: 1) a 
minimum payment that has to be made if asset utiliza- 
tion is below a pre-determined minimum threshold; 2) a 
usage based-payment that is made if usage is above 
the pre-determined minimum threshold and belowa pre- 
determined maximum threshold; 3) a penalty payment 
or surcharge is made if utilization is higher than the pre- 
determined maximum threshold; and 4) payments/re- 
wards based on incentive issues such as asset re-allo- 
cation or timely maintenance. 

[0078] The decision of whether to use usage-based 
billing based on one or more objective criteria based on 
an analysis of asset utilization is shown at decision point 
114. The decisions to charge either a minimum payment 
if a certain usage level is not met, or to charge a usage 
penalty above a maximum appropriate usage level, are 
shown by decision points 116 and 118 respectively. 
Thus, a variable-amount lease may be developed based 
on an analysis of objective criteria that is based in large 
part on the actual portion of an asset's life that is con- 
sumed by the asset user (e.g., usage hours). In a pre- 
ferred embodiment, the analysis is based on a pre-de- 
termined usage/pricing matrix in combination with actu- 
al usage for a specified time period. Once a level of max- 
imum efficiency has developed, leasing will typically be 
primarily, if not solely, based on asset usage billing. 
[0079] Through the use of the innovative leasing ar- 
rangement based on improved information availability 
to asset owner 92, the expenses of an asset user such 



as business 90 can be more accurately aligned with us- 
age and asset value consumption. More operational 
flexibility is provided to business 90. When leasing is 
based predominantly on asset usage billing, a business 

s 90 is able to adopt true off-balance sheet financing (i.e., 
the business is not required to note a financial obligation 
even in the footnotes of various financial reports as op- 
posed to standard off-balance sheet leasing where a 
company must disclose the lease in footnotes even if 

10 the lease does not show up on the balance sheet). At 
the same time, asset owner 92, can collect information 
from a variety of sources to maximize its relationships 
with its own vendors and customers to the benefit of all 
related parties by minimizing inefficiencies and provid- 

'5 ing appropriate accountability with maximum accuracy 
and validity tied to a minimal likelihood for mistakes, mis- 
information, or even fraud. 

[0080] These various factors can be adjusted dynam- 
ically by the asset owner 92 as a knowledge base is col- 
20 lected within its internal systems 99 and based on the 
actions of the other related parties. For a sophisticated 
asset owner with numerous fleets, it can conduct appro- 
priate analyses over all of its fleets to determine certain 
trends, which it may advantageously use. 

25 [0081] For example, if supplier 88 or maintenance or- 
ganization 86 is responsible for abnormally low asset 
utilization as opposed to actions within the control of 
business 90, then the risk associated with these possi- 
bilities can be shared between asset owner 92 and var- 

30 ious affected businesses 90 and transferred in some 
fashion to the responsible party. Thus, in a more pre- 
ferred embodiment of the invention, asset usage is ad- 
justed for maintenance considerations if business 90 is 
not responsible for its own maintenance. 

35 [0082] As shown at point 120, once the readily avail- 
able information is analyzed in view of the business re- 
lationship between an asset owner 92 and a business 
90, an invoice and billing module associated with the 
asset owner's own internal systems 99 is invoked that 

40 generates an appropriate invoice that is sent by the as- 
set owner to the business for payment and subsystem 
98 terminates at point 122. In a preferred embodiment, 
once subsystem 98 is developed for a particular situa- 
tion, and in the absence of an extraordinary event, in- 

45 voicing is automated based strictly on the objective cri- 
teria developed with minimal outside involvement. 
[0083] A key advantage of the present invention is 
that real-time data is collected by data acquisition device 
34 and timely transmitted to local controller 36 for trans- 

50 mission to database 78 of analysis controller 51. If in- 
complete or limited data representing only a small por- 
tion of the appropriate asset data points are transmitted, 
then appropriate decisions cannot be made to maximize 
asset utilization. For example, in the case of forklifts, 

55 both time of usage and distance traveled help provide 
information concerning asset utilization and mainte- 
nance considerations. 

[0084] Thus, the computer based system 30, includ- 
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ing subsystem 98, of the present invention provides a 
superior method for tracking and managing the assets 
31 than the prior art system 10. First, by providing the 
assets with the data acquisition devices 32 and the com- 
munications system 33 and 34, the operational charac- 
teristics and other information regarding the assets 31 
is automatically sensed and transmitted to the analysis 
controller 51 on a real time basis, without requiring hu- 
man intervention or assistance. Second, the analysis 
controller 51 is programmed to analyze such information 
as it is received and to automatically generate mainte- 
nance and warranty reports in response thereto. Third, 
all of the reports generated by the analysis controller 51 
are automatically delivered to the appropriate persons 
through the Internet 40, either directly to one or more of 
the administrative controllers 55 or by posting on a web 
site, electronic mail or similar mechanisms. Fourth, as 
shown by subsystem 98, the information can be used to 
maximize asset usage efficiency. As a result, the com- 
puter based system 30 facilitates the gathering, analyz- 
ing, and delivering of information relating to the procure- 
ment and utilization of the assets 31 so as to maximize 
productivity and to reduce operating costs and admin- 
istrative burdens to the benefit of all parties having a 
relationship with the asset and an interest in its perform- 
ance. 

[0085] The providing of maintenance to an asset 31 
is illustrated in further detail in Fig. 7. In addition to de- 
termining whether it is necessary to provide scheduled 
maintenance as noted at step 65 of Fig. 4A, changes in 
operational parameters associated with asset 31 as 
shown at point 150 may result in the generation of a spe- 
cific fault code if a maintenance problem is detected that 
requires a more expeditious response. The fault code 
may be generated by the asset itself using one or more 
sensors associated with operational parameters of as- 
set 31 as shown by point 152 and communicated to the 
data acquisition device 32. In addition, analysis control- 
ler 51 may analyze the raw operational data received 
from the asset 31 and compare it with analysis controller 
database 78 including the history of the specific asset 
31 as well as the history of similar assets from which 
maintenance trends may be determined as discussed 
with respect to Fig. 4C above. Based on an analysis of 
such trends, proactive lower cost maintenance can be 
timely performed that results in the avoidance of higher 
cost maintenance at a later date, which happens in the 
absence of real-time information available for review 
and analysis. 

[0086] A fault code may even be generated based on 
the actions of the asset operator. In a preferred embod- 
iment of the invention, an electronic checklist 154 is 
completed by the asset operator on a regular basis, 
which may include information concerning asset per- 
formance that is more detailed than that available from 
a review of raw operational parameters. In accordanc 
with OSHA requirements, for example, at the end of 
each shift, a forklift operator must complete a checklist 



concerning the performance of the asset during the shift. 
Some of the questions associat d with checklist 1 54 are 
directed to maintenance issues. Therefore, in a pr - 
ferred embodiment of the invention, checklist 1 54 would 

s be completed electronically at the asset 31, and trans- 
mitted by way of the data acquisition device 32 to anal- 
ysis controller 51 as discussed above. The information 
would be analyzed to determine if an OSHA/repair need 
is identified. Preferably, the analysis is automated in ac- 

10 cordance with a comparison of the operational status 
with pre-determined rules. For example, if a question 
asks if there is a hydraulic leak for a forklift and the an- 
swer is "yes", then maintenance would be appropriate, 
[0087] Once it is determined that maintenance of 

15 some type is required as shown at point 156 based on 
an analysis of the operational status of asset 3 1 , a main- 
tenance report 66 is generated as also shown in Fig. 4A 
and made available electronically at point 67' such as 
by the Internet or by posting on a website as also shown 

20 in Fig. 4A. The use of electronic mail, or the providing 
of real-time access to the raw data stored within data- 
base 78 by the maintenance organization 86, shown in 
Fig. 5, is also possible to generate the maintenance re- 
port 66. An advantage of providing a maintenance or- 

25 ganization 86 real-time access to the raw data repre- 
senting the operational status of asset 31 is that it may 
develop specialized analysis tools based on its own ex- 
pertise in maintenance, resulting for example in the cre- 
ation of specialized rules for use in automatically ana- 

30 lyzing raw data in determining whether maintenance is 
required, minimizing the need for manual review and de- 
termination. 

[0088] In a preferred embodiment, the priority of the 
proposed maintenance required 158 is noted on the 

35 maintenance report. For example, critical maintenance 
issues should take precedence over routine issues. 
Moreover, the system generally institutes an approval 
process as shown at point 160. For example, if the pro- 
posed maintenance is related to warranty work such as 

40 noted with respect to step 69 of Fig. 4B, the manufac- 
turer or supplier should approve the maintenance^ if a 
lessee is responsible for the proposed maintenance, it 
should approve the maintenance before it is performed. 
In some cases, the maintenance organization 86 itself 

45 approves the maintenance, such as when it has a con- 
tract that involves pre-payment of particular mainte- 
nance. Finally, as shown at point 162, in some cases it 
may be desirable to have the lessor or owner of the as- 
set have the ability to review and override any refusals 

50 to perform maintenance since it has the ultimate respon- 
sibility for asset 31. If no approvals are given, the proc- 
ess is terminated at point 1 64. A review of any automat- 
ed rules that generated a request for maintenance ap- 
proval may also be appropriate. When maintenance ap- 

55 proval is rejected, any automated rules that generated 
the original maintenance request can be fine-tuned by 
including the results of the approval process. Overtime, 
almost all maintenance requests should be generally 
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approved. Information regarding approval is stored in 
database 78. 

[0089] For preventative maintenance, it is expected 
that pre-approval will generally b granted by the nec- 
essary parties based on prior agreement as to the na- 
ture and timing of such maintenance. 
[0090] Once maintenance has been approved, a work 
order 166 is generated. As shown in Fig. 8, work order 
166 is sent electronically to appropriate maintenance 
personnel that contains all of the critical operating data 
required to effectively schedule and carry out the main- 
tenance. Typically, for example, the data includes hour 
meter reading, any fault codes, asset identification cri- 
teria, operator of record, contact information, and asset 
location. Moreover, based on information contained 
within the fault code or retrieved from the knowledge- 
base, information concerning anticipated parts may also 
be provided as well as the nearest location from where 
they may be retrieved (e.g., at a customer location, or 
from a local servicing dealer). Finally, the work order 1 66 
preferably contains the past recent history of the partic- 
ular asset 31 so that the mechanic can use this informa- 
tion to expedite maintenance. 

[0091] In a preferred embodiment of the invention, the 
work order 166 is transmitted electronically to a hand- 
held device 168 associated with specific maintenance 
personnel assigned to carry out the maintenance. De- 
vice 168 includes an appropriate graphical user inter- 
face (GUI) that permits the receiving and transmitting of 
both alphanumeric and graphical based information. Ex- 
amples of hand held devices include a variety of sys- 
tems produced that use either the Palm® operating sys- 
tem from Palm, Inc. or a sub-set of Microsoft® Win- 
dows® from Microsoft Inc. Moreover, in a more pre- 
ferred embodiment of the invention, the hand held de- 
vice 168 is in real-time two-way communication with 
analysis controller database 78. Thus, under appropri- 
ate circumstances the handheld device 168 can access 
such things as dealer billing systems, inventory listings, 
customer work order approval records, and fleet man- 
agement information. Rather than having the work order 
include the past recent history of the asset 31 to be serv- 
iced, it is possible to use the two-way communication 
link to request the necessary history when advanta- 
geous to do so. 

[0092] Once the maintenance is completed, handheld 
device 168 is used to update database 78 as shown at 
point 170, including labor information and an identifica- 
tion of any parts required to effect a repair. If not already 
clear based on the contents of database 78, the inven- 
tory location from which any parts were pulled should 
also be provided. Ideally, the information is transmitted 
on a real-time basis from the handheld device 168. Al- 
ternatively, however, the information can be transmitted 
upon routine synchronization of the handheld device 
with database 78. It is also possible to manually enter 
the information into the database 78. 
[0093] The maintenance information is passed to da- 



tabas 78 where it may be used to g nerate mainte- 
nance tracking reports 172, and compr hensive invoic- 
es 174 listing both labor and part costs. Since the infor- 
mation is integrated with pre-existing asset information, 

5 no rekeying is required. Moreover, as noted abov with 
respect to Fig. 4C, the complete maintenance history of 
a particular asset or class of assets may be reviewed 
and analyzed in detail for specific trends of interest. 
[0094] In addition, when parts are used, as shown at 

10 point 176, system 30 preferably permits comparison of 
the parts used with existing inventory for the specified 
parts storage location. Based on maintenance trends 
associated with a class of assets 31 or a specific asset 
31, it is possible for the system to automatically order 

15 replacement parts for an inventory location if the number 
of parts in a particular inventory fall below a pre-deter- 
mined threshold as shown at points 178 and 180. The 
threshold is calculated at least in part based on an anal- 
ysis of the prior maintenance of both the asset 31 and 

20 the class of assets associated with the asset. Other fac- 
tors may include the age of the class of assets, the time 
of the year, usage trends and the like. As one example, 
in the winter different parts may be required as opposed 
to in the summer. As another example, more tires may 

25 be required for a forklift asset if a number of the assets 
are reaching a preventative maintenance stage where 
tires have to be replaced. The system terminates at 
point 182. 

[0095] It is also possible to provide online copies of 

30 parts catalogs including part numbers and exploded 
views of parts, including to hand held device 168. In 
some cases a comparison table of equivalent parts may 
be provided to reduce part acquisition timing or cost. 
Moreover, system 30 preferably keeps track of part 

35 availability and cost throughout a parts availability net- 
work. Thus, no one party is required to keep as many 
items in stock since ready access to items stored at a 
different location is possible. Transaction costs in locat- 
ing and requesting items from different locations is min- 

40 imized since the information is readily stored and acces- 
sible from system 30. Item stock reduction at any one 
location is also possible for the reasons discussed 
above where careful quantity controls are implemented. 
[0096] Under some circumstances it may even make 

45 sense to have a central parts depository with inventory 
actually held and controlled by a third party such as a 
courier service. For example, the courier service can 
ship parts as needed to effect a repair or replenish a 
reduced inventory at a remote location. With a central 

so depository, the cost of maintaining the inventory can be 
borne by the party having the best ability to do so. For 
example, if an asset owner 92 has many businesses 90 
using a class of assets 31, it may be able to provide 
economies of scale to the businesses by being respon- 

55 sible for ordering and stocking inventory parts for use 
by all affected businesses. Non-related businesses may 
also be provided access to a part inventory at a higher 
cost, giving them a further incentive to actively partici- 
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pate in system 30 to enjoy improved economies of scale. 
Thus, system 30 provides enhanced customer servic 
through reduced cost and a more efficient part access 
and ordering process. 

[0097] Inventive system 30 provides a number of ad- 
ditional advantages for maintenance. For example, 
through the use of electronic information transmission 
and analysis, maintenance information is transferred 
and available real-time for review and for the initiation 
of necessary actions such as approval, the tracking of 
performed maintenance, the ordering of replacement 
parts to replenish depleted inventories, and automatic 
invoice generation. Since asset 31 communicates its 
own maintenance needs in consultation with an appro- 
priate knowledgebase associated with database 78, hu- 
man intervention is minimized. As more information is 
gathered over time, the scheduling of preventative 
maintenance can be optimized to eliminate either too 
little or too much maintenance. Further, system 30 au- 
tomates a very paper-intensive and time cumbersome 
process by permitting direct communication with the 
various information elements associated with an asset 
31 . As a result, the flow of data is more effectively con- 
trolled, dispersed, routed, monitored, and acted upon. 
In practice, the number of people involved in the main- 
tenance process can often be reduced while the speed 
of providing maintenance can be increased. Thus, po- 
tential downtime and related performance issues can be 
more timely addressed. 

[0098] A further aspect of the invention, authorization 
subsystem 200 within system 30, is illustrated in Fig. 9. 
Authentication to access an asset 31 is tied to pre-de- 
termined rules. Specifically, authorization subsystem 
200 keeps track of all individual users 85 using an asset 
31. It prevents asset utilization by uncertified users 85. 
System 30 may require that a user 85 be trained or cer- 
tified to utilize certain assets 31 . Even if trained or cer- 
tified, system 30 may only allow a user 85 to access an 
asset 31 for a limited period of time within a pre-set time 
range (e.g., OSHA or other work regulations may only 
permit access for ten (10) hours within every twenty-four 
(24) hours). Further, authentication may be denied if a 
user 85 is found to have too many accidents. By tracking 
regulation requirements, training or certification issues 
and even accident rates, an asset 31 is more likely to 
be well maintained and well utilized. As a result, there 
are reduced operating costs, minimized potential fines 
through enhanced regulation compliance, and pro- 
longed asset life through appropriate usage. 
[0099] Apart from user 85, maintenance considera- 
tions may make an asset 31 unavailable. If critical main- 
tenance is required, the unavailability of an asset 31 
may prevent unwanted problems resulting from inappro- 
priate continued use, again reducing operating costs 
and extending asset life. 

[0100] In other situations, authorization subsystem 
200 is essentially a beneficial subscription service. For 
example, a single asset 31 may be available to different 



users at pre-set times based on a reservation system, 
which is tracked through authentication subsystem 200. 
A prior reservation may take precedence over a desire 
to use an asset without such a reservation. Alternatively, 

5 access to an asset 31 may be terminated if payments 
to a third party such as maintenance organization 86, 
asset supplier 88 or asset owner 92 are in arrears. Of 
particular benefit, even when authorizing access, the 
ability to track usage with respect to a particular user 85 

f o permits different monetary or time-based asset access 
rates depending on the specific user or entity associated 
with that user. 

[0101] As shown at point 201, a record of user 85 is 
created that may be stored in analysis controller data- 
's base 78. The information associated with user 85 pref- 
erably includes such data as a unique user code, user 
identification information (e.g., employer, location, ad- 
dress, and contact information) the number/class of as- 
sets for which the user is permitted access, safety 

20 record (e.g., number of accidents associated with each 
asset and over what period of total usage or time), and 
training or certification records. 
[0102] A user attempts to access a particular asset at 
point 202. The access may be through the use of an 

25 access device 204 associated with the particular user 
(e.g., access card, magnetic key, or key pad code) and 
a corresponding approval device 206 associated with 
an asset 31 that is connected to data acquisition device 
32 for authorization confirmation. In turn, as noted 

30 above, data acquisition device 32 is associated with 
transmitter 33, which is in selective communication with 
local controller 36. As shown at point 208, when a user 
attempts to access asset 31 for use, an attempt is first 
made to access remote system 50 for authorization. If 

35 communication is not possible, an attempt is next made 
to communicate with local controller 36 at decision point 
210, which preferably includes a data cache for at least 
a sub-set of users 85 associated with a particular facility 
where an asset 31 is located. The data associated with 

40 local controller 36 may not be as up to date as that avail- 
able from direct access to analysis controller database 
78. In turn, if communication is not possible even with 
the local controller, an asset cache of data 212 associ- 
ated with a particular asset 31 may optionally be avail- 

45 able for access by approval device 206, as shown at 
decision point 214. Once again, the data may not be as 
up to date. On the other hand, at times, the data cached 
within asset cache 212 or local controller 36 may be 
more up to date than that associated with system 50. 

so The appropriate data is communicated between asset 
cache 212 and local controller 36, and then between lo- 
cal controller 36 and system 50, as communication be- 
tween the appropriate devices takes place. 
[0103] Once data related to asset 31 and user 85 is 

55 located, system 30 determines if user 85 is an author- 
ized user for asset 31 at decision point 216, or if the 
asset 31 itself is available for user at decision point 218 
in accordance with pre-determined rules or considera- 



15 



29 



EP 1 315 112 A2 



30 



tions such as those noted abov . If authorization is not 
granted, a communication interfac 220 associated with 
asset 31 preferably gives the reason for the denial and 
the steps required to obtain authorization 222. It may 
even be possible to use communication interfac 220 to 
provide interactive training and certification under some 
circumstances. As suggested above, a communication 
interface 220 may even be used to complete an inter- 
active asset checklist as discussed above before and 
after asset operation by each user 85. Finally, even if 
approval is given, confirmation as well as special in- 
structions or information of importance to user 85, col- 
lected at point 224 (e.g., remaining access time, timing 
for re-training or re-certification, or next scheduled 
maintenance) may be displayed to the user. 
[01 04] Finally, if a user 85 is not authorized, either be- 
cause of communication problems or issues associated 
with either the user or the asset itself, preferably some 
type of supervisory override, such as a master access 
device or code and shown at decision point 226, may 
be selectively implemented between devices 204 and 
206 to permit asset utilization. Even if there is such an 
override, however, information associated with asset 
utilization is still recorded and communicated as taught 
above. 

[0105] Finally, any pertinent authentication subsys- 
tem data is stored in database 78. Moreover, pre-deter- 
mined rules may be established that provide automatic 
instructions to system 30 when such authentication sub- 
system data should be communicated to a third party 
such as a supervisor, trainer, or security personnel as a 
result of a user attempting to access an asset 31 as 
shown at point 230. For example, if a user 85 needs to 
have additional training, that information needs to be 
communicated to the appropriate party (e.g., supervisor 
and trainer). Training may take place using internal per- 
sonnel or it may be outsourced to a vendor 93 (shown 
in Fig. 5) in a manner similar to maintenance, as dis- 
cussed above. System 30 makes it possible to schedule 
training and even track the cost and corresponding ben- 
efits of training through access to real-time and historical 
asset or user data not generally available except in ac- 
cordance with the teachings of the present invention. As 
another example, if unauthorized personnel attempt to 
use an asset 31 , it may be appropriate to send an urgent 
message to appropriate security personnel at the loca- 
tion of asset 31. Finally, authentication subsystem 200 
terminates at end point 232. 

[0106] As shown most succinctly in Fig. 5, numerous 
parties have access to analysis controller database, 
which stores data with respect to asset 31 and various 
parties having a relationship to that asset. The collected 
data may be used or analyzed in any one of a number 
of different ways depending on the interests of the party. 
For example, a maintenance organization is interested 
in using the data available to improve maintenance and 
reduce associated costs; asset supplier 88 desires to 
examine and minimize warranty issues; and asset own- 



er/leasing company 92 desires to appropriately maxi- 
mize its return on investment, a desir shared with each 
business 90. From the perspective of an individual user 
85, such issues as appropriate training and certification 

5 have also been discussed. 

[0107] "What if inquiries are particularly important to 
successful implementation of system 30. For example, 
when proposing the use of system 30 to a party such as 
a potential customer, the ability to analyze historical data 

10 and performance with respect to similarly situated cus- 
tomers is invaluable to provide a breakdown of costs 
and possible cost savings. As noted above, with appro- 
priate information, an asset owner 92, such as a leasing 
company, may be able to share in part of the risk of asset 

15 utilization with appropriate data access and control. 
[0108] To facilitate these types of analyses, it is im- 
portant to have robust access to analysis controller da- 
tabase 78, which can actually be one or more databases 
of information tied together so as to be accessible for 

20 the purpose of an analysis of system 30. In a preferred 
embodiment, hand held device 168 or a similar type of 
computing device provides a desirable access point to 
database 78. 

[0109] However, before the parties can take advan- 

25 tage of system 30, it is essential to create a foundational 
base of information that provides a framework for further 
analysis. Ideally, pre-created forms or templates help fa- 
cilitate data collection and analysis. For example, when 
talking to a potential customer, it would be helpful to 

30 have access to cross-reference materials related to 
competitor assets, lease pricing rate factors, historical 
data and the like. Certain query forms can be used to 
collect relevant raw data and other query forms can be 
used to retrieve useful data based on a consideration of 

35 the raw data to provide the basis for recommended 
courses of conduct to promote safe utilization and effi- 
ciency while reducing costs. Thus, the actual analysis 
typically takes place at a central location having the ap- 
propriate computational resources with the results pref- 

40 erably being transmitted to hand held device 1 68. Under 
some circumstances, an analysis is possible directly on- 
site using the data collected and analyzed without direct 
access to database 78 based on a sub-set of data and 
logic protocols in the form of analysis tools stored on 

45 hand held device 168. 

[0110] Even when not in real-time contact with data- 
base 78, hand held device 1 68 is often invaluable. It per- 
mits the automation of survey data entry by an account 
manager so that information concerning assets 31 , a 

50 business 90, individual users 85, and other related par- 
ties may be entered on-site and later transferred to da- 
tabase 78. The use of paper forms and manual transla- 
tion of information is eliminated, speeding up data entry. 
For example, in the past an account manager might 

55 have handled more than twenty (20) data sheets that 
tracked specifications of the current fleet of assets 31 
for a new customer business 90. The data sheets were 
taken back to the office and manually entered into a local 
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database. Simultaneously, an intermediate source of er- 
ror related to manual keying or a similar translation 
method is eliminated. 

[0111] A data acquisition and analysis subsystem 300 
is illustrated in Fig. 10. Subsystem 300 facilitates the 
collection of raw fleet survey data 302 upon initiation of 
system 30 by a party so that a baseline level of data may 
be provided to system 30 for consideration and analysis. 
An account manager 304 collects raw data with respect 
to each affected asset 31 and all parties having interac- 
tion with the asset such as the parties identified with re- 
spect to Fig. 5 above. Of course, other parties may also 
contribute fleet survey data if they have interaction with 
an asset 31 . The data is preferably inputted into a hand- 
held device 168 using pre-defined forms 306, transmit- 
ted to a desktop computer 308, and then ultimately 
stored in analysis controller database 78. To help with 
analysis of particular data, the process may be re- 
versed, with data pulled from database 78 to desktop 
computer 308, transmitted to hand held device 1 68, and 
used by account manager 304 to perform a desired 
analysis for any affected party. 
[0112] Preferably, hand held device 168 uses an op- 
erating system 312 provided by Palm, Inc. Aforms man- 
ager 314 from Puma Technologies, Inc. known as the 
Satellite Forms software development package is used 
to generate data forms 306, which are used to enter the 
required information or display stored data from hand 
held 168 or from analysis controller database 78. When 
collecting raw data, account manager 304 follows inquir- 
ies associated with form 306 to enter required informa- 
tion. In contrast to manual methods, it is preferably pos- 
sible to advise when inappropriate data is entered or if 
a field is missed. Thus, any data entry errors can be ad- 
dressed on the spot when the source of the original data 
is readily available. Hand held device 168 stores locally 
collected data 316 such as fleet survey data 302, may 
include retrieved data 318 from database 78, and a 
number of different analysis tools 320 for evaluating the 
stored data. For example, one analysis tool 320 may use 
a set of rules to estimate the total life of an asset under 
the circumstances currently in place at a business 90 
and compare them to known "best practices" for the 
same asset along with proposed process changes to in- 
crease asset life to reach the "best practices" level. 
[0113] Preferably, computer 308 includes an operat- 
ing system 322 provided by Microsoft such as Win- 
dows® 98, Windows® Millenium or Windows® 2000. It 
has a plug-in 324 provided by the party responsible for 
hand held operating system 312 to provide a synchro- 
nization conduit 326. Synchronization is handled 
through a conventional or USB serial data port on the 
desktop computer 308 and a cradle hardware device 
328 associated with device 168. During use of synchro- 
nization conduit 326, data values and associated data 
stored on hand held device 168 and desktop computer 
308 are interchanged in accordance with parameters 
provided in forms manager 314 and a corresponding 



forms manager computer plug-in 330 on desktop com- 
puter 308. Desktop computer includ s data from hand 
held device 168, data from database 78 to either be 
used locally by the computer or transferred to hand held 
5 device 168, data received from device 168 or manipu- 
lated locally using one or more analysis tools 332, and 
data to be transmitted to database 78 for long-term ma- 
nipulation or storage. 

[0114] For example, when using subsystem 300 to 

10 transfer fleet survey data 302 that has been placed into 
hand held device 168 as locally collected data 316. The 
data transmitted includes both data elements and lists 
of value fields identifying a data source and the specific 
data values populating each data element. The data is 

is then transferred to database 78 from desktop 308 in ac- 
cordance with pre-determined rules. Preferably, the da- 
ta is associated with fixed fields that are consistently de- 
fined between hand held device 168 and database 78 
so that the data merely populates the appropriate fields 

20 within database 78 after it is transferred from the hand 
held device. Alternatively, the data may be uploaded into 
a local analysis tool 332 of desktop 308 such as a da- 
tabase or spreadsheet program for final manipulation 
and then storage in asset controller database 78. 

25 [0115] More particularly, in a preferred embodiment 
of the invention an account manager 304 who is about 
ready to visit a business 90 determines the type of in- 
formation that is relevant to be collected during the visit. 
Using the desktop computer, a list of values as well as 

30 data query forms are downloaded from asset controller 
database 78 and stored on the local desktop computer 
hard drive, and then transferred to hand held device 
168. For example, when first taking an inventory of pre- 
existing assets for a new business 90, a list of valid value 

35 identifiers for forklift analysis may include the following 
data elements: 

1) Overall customer information 

2) Customer division information 

40 3) Locations of facilities within each division where 
forklifts are used 

4) Departments within each facility that use the fork- 
lifts 

5) Broad descriptions of the types of ways or indus- 
45 tries for which the forklifts are used 

6) For each forklift: 

a) Manufacturer/Supplier 

b) Power supply type 
50 c) Mast type 

d) Tire type 

e) Forklift attachments 

f) Forklift type/model 

g) Forklift serial number 

55 h) Any label used by a customer to uniquely 

identify the forklift 
i) Date the forklift went into service 
j) Number of hours that the forklift has been in 
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use according to its meter. 

k) Lease/rental contract information 

I) Maintenance history 

m) Maintenance contracts. 

n) Forklift dealer 

o) The number of months/and/or usage hours 
covered pursuant to the manufacturer/supplier 
warranty. 

p) Original purchase cost 
q) Manufacturing date 

r) Forklift condition (e.g., based on a scale such 
as new or used) 

s) Application rating (e.g., heavy, medium or 
light) 

t) Administration fees charged for providing fi- 
nancing/maintenance or the like 
u) Criteria providing feedback concerning the 
number of hours at which preventative mainte- 
nance should be performed 
v) Capacity, typically in pounds or kilograms 
w) Number of hours or shifts the forklift is used 
each day 

x) Number of days a week that a forklift is used 

[0116] The tables are downloaded to hand held de- 
vice 1 68 using synchronization conduit 326 and the re- 
lationship between forms manager 314 and forms man- 
ager computer plug-in 330. In practice, the transfer of 
data value tables and their related values has also in- 
cluded the use of a program written in a product called 
Sybase Powerbuilderfrom Sybase, Inc. Under such cir- 
cumstances analysis controller database 78 is a Sybase 
database. Further, desktop computer 308 may include 
a different database manipulation program called 
DBASE acting as one of the local analysis tools to re- 
view and possibly manipulate data received from hand 
held_device 168 or analysis controller. database78 be- 
fore forwarding it to the receiving device. 
[0117] The collection of fleet survey data 302 is mere- 
ly an example of subsystem 300 in use. Moreover, even 
when an account manager 304 is collecting fleet survey 
data 302, it is preferred that if some of the data associ- 
ated with a survey is already stored in database 78 (e. 
g., customer contact information, divisions, or asset lo- 
cations), it is used to pre-populate appropriate forms 
306 to simplify redundant data entry by the account 
manager. Further, if an error exists based on an inaccu- 
racy in the pre-existing data, account manager 304 can 
correct it. 

[0118] The collected and manipulated data provides 
a starting point for each asset 31 going forward as well 
as a base foundation for immediate asset fleet analysis 
since at least some historical data has preferably been 
collected for existing assets. Thus, even at the begin- 
ning of the utilization of system 300, the initially collected 
data can be analyzed in accordance with pre-existing 
data involving other fleets, best practices, and the like, 
to provide immediate guidance on how to improve cur- 



rent fleet utilization and efficiency. The same subsystem 
may be used to transfer data and recomm ndations 
back to hand held device 168, except that this time forms 
306 perform a data pr sentation function as opposed to 
s a query function. As suggested above, som analysis 
of data may be performed directly on hand-held device 
168 although more sophisticated analysis tools 332 are 
typically associated with desktop computer 308 or asset 
controller 51 in view of their enhanced computational 
10 power and storage capabilities. 

[0119] Subsystem 300 has been shown using syn- 
chronization. It is recognized of course, that real-time 
access is also possible between hand held device and 
either asset controller 51 or desktop computer 308 with- 
15 out the need to use cradle 328. An advantage of real- 
time access between a hand-held device 168 and data- 
base 78 is that information may be immediately trans- 
mitted and received, providing access to the full range 
of data values and associated data available in data- 
20 base 78. The uploading and downloading of pre-created 
data forms 306 to help facilitate the collection and anal- 
ysis of data is also expedited. Further, under some cir- 
cumstances real-time error checking may be available. 
For example, if an account manager 304 indicates the 
25 number of assets available at a physical location and 
the actual number in database 78 is different, the man- 
ager can be asked to undertake verification while still 
present at the physical location. Otherwise, to the extent 
that there are discrepancies, they may be considered 
30 after data synchronization takes place. 

[0120] The same methodology discussed with re- 
spect to subsystem 300 may also be used by mainte- 
nance personnel as discussed with respect to Fig. 8 
above. Work order 166 acts as a pre-populated form 306 
35 transmitted to a hand held device 168. Once the main- 
tenance is completed a different form 306 may be used 
to communicate the_necessary maintenance labor and 
parts information so that a maintenance tracking report 
1 72, invoice 1 74, and determination of inventory replen- 
40 ishment 178 may be implemented. 

[0121] The system 30 provides the ability to take data 
concerning any asset 3 1 and the interaction of that asset 
31 with any party, including user 85, maintenance or- 
ganization 86, asset manufacturer or supplier 86, busi- 
es ness 90, asset owner 92, or other parties/vendors 93. 
Moreover, groups of assets may be combined. Thus, it 
is possible to analyze data to identify the cost of owning 
or using any asset 31 and the productivity of that asset. 
Moreover, based on an adequately large statistical uni- 
50 verse of data it is possible to benchmark asset utilization 
and cost against others in similar circumstances to iden- 
tify best practices. Thus, it is possible for efficiency to 
be maximized while simultaneously minimizing unwant- 
ed waste by identifying time and cost saving opportuni- 
55 ties. It is also possible to determine those parties pro- 
viding best practice services with respect to asset utili- 
zation (e.g., maintenance) so that their services can be 
expanded and appropriate recognition given for their ef- 
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forts. Alternatively, it is possible to identify parties pro- 
viding unacceptable services so that appropriate reme- 
dial action may be taken (e.g., a user 85 has inadequat 
training to properly use an asset so additional training 
needs to be provided). 

[0122] The ability to benchmark asset-related data is 
one of the functions of the data acquisition and analysis 
subsystem 300. In a preferred embodiment, bench- 
marking functionality is part of a comprehensive asset 
tracking and management system 30. However, in alter- 
native embodiments, benchmarking functionality can 
stand alone so long as there is asset data to benchmark. 
[0123] Fig. 11 is a schematic block diagram of a com- 
puter-based system for tracking and managing a plural- 
ity of assets in accordance with the invention. The Fig- 
ure provides a high level illustration of how benchmark- 
ing functionality can be incorporated into the system 30. 
In order for the system 30 to perform benchmarking 
functionality, an analyst 400 must initiate contact with 
the system 30. The analyst can be a user 85, a super- 
visor, and account manager, or any other person inter- 
ested in benchmarking asset related data. The analyst 
400 can be associated with any number of different or- 
ganizations, including an asset supplier 88, an asset us- 
er such as a business 90, an asset maintenance organ- 
ization 86, an asset owner such as a leasing company 
92, or any other interested party or vendor 93 (collec- 
tively "interested party"). The entity controlling the sys- 
tem 30 (such as an Application Service Provider in a 
preferred embodiment) can control the types of data that 
a particular analyst 400 can access. Different analysts 
400 can be given different access rights. The system 30 
can distinguish different analysts 400 on the basis of 
their relationship with an interested party or some other 
attribute or characteristic. Data access rules can also 
be defined or influenced by the interested party that al- 
lows the data to be used in a pool of_potential_bench- 
marking information 408. In a preferred embodiment of 
the invention, the degree of participation by an interest- 
ed party is solely at the discretion of the interested party. 
The benefit of being able to benchmark against the data 
of other groups is the primary motivator for encouraging 
a particular organization to allow the greatest possible 
access to its data. In a preferred embodiment, an organ- 
ization is only allowed access to the data of other inter- 
ested parties to the extent that the organization allows 
those interested parties access to its own data. Interest- 
ed parties such as manufacturers, dealers, equipment 
owners, equipment users, third party asset manage- 
ment groups, publications, financial institutions, or any 
other type of interested party can control the terms in 
which their data is available in the pool of potential 
benchmarking information 408. Access to certain types 
of data can be limited to certain circumstances, or ex- 
cluded altogether. Reciprocity of data access can be in- 
corporated into the system 30 to maximize the willing- 
ness of an organization to make its data available to the 
benchmarking pool 408 in the broadest possible way. 
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[0124] The analyst 400 may access the system 30 
through any number of different access devices 402. 
The access device can be a desktop computer 308, a 
hand held device 168, or any other computer or device 

5 capable of interfacing with an information network or 
database , such as an analysis controller database 78. 
In one form of benchmarking, the analyst 400 desires to 
compare a particular asset 31 (a "target" asset) against 
a pool of potential benchmarking information 408 that 

to includes data relating to one or more benchmarking pool 
assets 406. In another common form of benchmarking, 
there is no target asset 31, and the benchmarking sys- 
tem 30 is being used to generate aggregate level infor- 
mation across an range of benchmarking pool assets 

15 406. Such information can be used to determine "best 
practices" relating to group of assets 406. Of course, 
such aggregate level information can be compared to 
other aggregate level information using the system 30. 
The analyst 400 can configure the system 30 in a highly 

20 flexible manner in order to compare or contrast as many 
different sets of data as desirable. 
[0125] Benchmarking asset characteristics 404 re- 
quires that such characteristics exist on the system 30. 
An analyst 400 can use the system 30 to define a virtu- 

25 ally unlimited number of asset characteristics 404. An 
asset characteristic 404 is a type of attribute relating to 
an asset 31. Different types of assets 31 can have some 
identical characteristics (e.g. most assets can have an 
asset type characteristic; some similar characteristics 

30 (e.g. most assets will have financial and accounting 
characteristics); and some totally different characteris- 
tics (e.g. a computer will not have a characteristic relat- 
ing to the carrying capacity of a forklift). The valid forklift 
identifiers listed above are examples of potential asset 

35 characteristics. 

[01 26] A data value is the particular characteristic val- 

_ ue of_a particular asset^For example, height can be a 
characteristic, but a height of 48 inches is a value for 
the characteristic of height. Similarly, cost can be a com- 

40 rnon asset characteristic 404. A data value for the asset 
characteristic of cost is the purchase price of the partic- 
ular asset. 

[0127] Benchmarking is generally performed to com- 
pare different data values relating to an identical or at 

45 least somewhat similar asset characteristic, e.g., annual 
cost information could be compared with total lifetime 
cost information. However, the system 30 need not 
place any limits on the types of characteristics 404 that 
can be compared for benchmarking purposes, although 

50 in such a system 30 the analyst 400 may need to apply 
some intelligence with respect to the results. 
[0128] Asset characteristics 404 can include virtually 
any information relating to an asset 31. There are at 
least eight different potential categories of asset char- 

55 acteristics 404 in a preferred embodiment of the inven- 
tion. The various categories can overlap, and should not 
be considered in an overly rigid or technical manner. 
One category of asset characteristics 404 is asset-type 
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information. For example, an asset 31 can be th type 
of a forklift. However, an asset 31 can also be a partic- 
ular model of forklift. Asset type characteristics 404 can 
include type, model, manufacturer, and other related in- 
formation. A second category of asset characteristics 
404 is application information, which includes such at- 
tributes as operating environment, functionality, speed, 
energy consumption, and other information relating to 
an asset 31 . A third category of asset characteristics 404 
is asset usage information, such as the number of hours 
per unit of time that an asset 31 has been used, the life 
expectancy of the asset 31 , and other information relat- 
ing to the use of the asset 31 . A fourth category of asset 
characteristics 404 is plant activity information. Plant ac- 
tivity characteristics 404 include location, shifts used, 
hours available, and other plant related information. A 
fifth category of asset characteristics 404 is manufac- 
turer information, such as the year an asset was made, 
contractual obligations by the manufacturer with respect 
to the asset 31, and other manufacturer related charac- 
teristics 404. A sixth category of asset characteristics 
404 is maintenance information, which includes the type 
of work performed, the date the work was performed, 
who performed the work, and other maintenance related 
information. A seventh category of asset characteristics 
404 is accounting information, which can include the 
purchase price, costs incurred after purchase due to 
maintenance work or other enhancements, fuel expens- 
es, depreciation, and other financial and accounting in- 
formation. Accounting information can include such 
metrics as average or total cost per a period of time. An 
eight category of asset characteristics 404 is entity in- 
formation, and can include such attributes as owner, us- 
er, manufacturer, supervisor, maintenance organiza- 
tion, lessor, and other entity-related characteristics 404. 
[0129] Benchmarking pool assets 406 can be select- 
ed on the basis.of a shared characteristic 404 (for ex^_ 
ample, the characteristic of being a vehicle), a shared 
data value for a particular characteristic (for example, 
all vehicles with a purchase price less than $20,000), or 
through any other process or means. The analyst 400 
can select on an individual asset by individual asset ba- 
sis which assets 31 are benchmark pool assets 406. 
Similarly, the analyst 400 can select on an individual as- 
set by individual asset basis, which assets are target as- 
sets 31 . In a preferred embodiment, asset selection for 
benchmarking purposes should share some relevant 
characteristic 404 or data value. In the example dis- 
played on the figure, the target asset 31 is a forklift. 
Benchmarking pool assets 406 include forklifts of differ- 
ent sizes, vehicles of similar structures, machines with 
similar purposes, and some other vehicles such as hel- 
icopters that could be used to move equipment. All of 
the benchmark pool assets 406 in the Figure do share 
the characteristic of a carrying capacity, but such com- 
monality is not required for the system 30 to function. 
All relevant data can be stored on the analysis controller 
database 78 so that future data can be benchmarked 



against past data, and to otherwise maximize the poten- 
tial pool of benchmarking information 408 that can be 
utilized by the system 30. 

[0130] Just as the analyst 400 has significant flexibil- 

5 ity with respect to choosing which assets 31 are includ d 
in the pool of potential benchmarking information 408 
for a particular benchmark calculation, the analyst also 
has significant flexibility with respect to choosing which 
characteristic or characteristics are included in the pool 

10 of potential benchmarking information 408. The analyst 
400 can include accounting data, asset type informa- 
tion, usage information, plant activity information, main- 
tenance information, manufacturer information, entity 
information, some combination of the above, or some 

15 other type of asset characteristic 404. 

[0131] The system 30 applies a benchmark heuristic 
to generate a benchmark value from the pool of potential 
benchmarking information 408. The benchmark value 
represents some relationship to the data values of a par- 

20 ticular characteristic 404 or set of characteristics 404. If 
a target asset 31 is being compared to the pool of po- 
tential benchmark information, data values for one or 
more asset characteristics 404 of the target asset 31 can 
be compared to the benchmark values for one or more 

25 asset characteristics 404 in the pool of potential bench- 
marking information 408. 

[0132] In a preferred embodiment, a benchmark value 
will be a numerical or financial value. Numerical values 
can be aggregated, averaged, subtracted from each 

30 other, or otherwise manipulated or processed in accord- 
ance with the benchmark heuristic. In alternative em- 
bodiments, non-numerical values such as model types, 
names, and other non-numeric data can be "bench- 
marked" but such processing is often merely just a form 

35 of sorting data. 

[0133] Fig. 12 is a schematic block diagram illustrat- 
ing how asset information for multiple entities can be 
used for benchmarking purposes. In a preferred embod- 
iment, different entities or organizations contribute their 

40 individual pools of benchmarking information to an anal- 
ysis controller database 78. An individual participating 
organization 409 which can be any of the interested par- 
ties defined above, can utilize the data pools of other 
participating organizations 409 in order to enlarge the 

« potential data pool for benchmarking purposes. Asset 
characteristics that would cause an asset 31 to be iden- 
tifiable to a particular participating organization ("organ- 
izationally identifiable data") can be hidden from other 
participating organizations 409 so that organizations are 

50 encouraged to participate in the system 30 without fear 
of outside entities or even competitors gaining access 
to confidential or proprietary information. 
[0134] In a preferred embodiment, an application 
service provider 410 or similarly neutral third party man- 

55 ages the system 30 in order to encourage the involve- 
ment and data sharing of participating organizations 
409. The ability to pool information from a wide variety 
of different sources is an important feature of the inven- 
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tion because many organizations do not have a suffi- 
ciently large data pools relating to a particular type or 
model of asset 406 to conduct meaningful benchmark- 
ing analysis. Without statistically significant benchmark- 
ing results, it is nearly impossible to implement a "best 
practices" approach resulting from insights learned from 
benchmarking. Moreover, an industry wide "best prac- 
tices" approach requires industry wide data. Only by in- 
cluding data from a wide variety of organizations in an 
industry can the system 30 generate benchmarking data 
in which an organization can truly measure itself against 
the practices of the organizations that lead the industry. 
[0135] Fig. 13 is a flow chart illustrating one example 
of how benchmarking can be performed. The first step 
in the process is determining at 412 which asset or as- 
sets are to be included in the benchmarking information 
pool for the particular analysis being conducted. Assets 
can be selected on an ad hoc (asset by asset) basis by 
having the analyst 400 manually select such assets 408 
using the access device 402. In a preferred embodi- 
ment, assets 406 are selected on the basis of having a 
particular characteristic (for example, the characteristic 
of being a vehicle and having a maximum speed) or on 
the basis of having a particular value of the character- 
istic (for example, having a maximum speed of less than 
40 miles per hour). The system 30 provides the analyst 
400 with significant flexibility in selecting assets 406 for 
inclusion into a particular benchmarking analysis. 
[0136] The second step in the process is selecting the 
characteristic(s) 404 (and the corresponding data val- 
ues for the characteristic(s) 404) related the benchmark 
pool assets 406 that are to be included in the pool of 
benchmark information 408. The analyst 400 can select 
as many or as few characteristics 404 for benchmarking 
analysis. If certain characteristics 404 or data values 
were used to identify which assets are included as 
benchmarking pool assets 406,„.those same character-, 
istics do not have to be selected for inclusion in the 
benchmarking analysis. For example, the characteristic 
404 of asset type and the data value of forklift can be 
used to include only forklifts in the pool of benchmarking 
information, but the characteristic being benchmarked 
could be annual cost, or some otherfinancial or account- 
ing characteristic. 

[0137] The third step in the process requires the an- 
alyst 400 to decide whether a comparison is desired at 
416. A comparison will not always be desirable or even 
possible if target asset 31 information does not exist. In 
such instances the analyst 400 can forego a compari- 
son, and the system 30 goes to step 422, where the sys- 
tem 30 generates analyses, illustrations, and reports re- 
lated to the selected assets and the selected character- 
istics. An example of step 422 processing is when a pro- 
curement decision is being made for a totally new type 
of asset. Assets 31 that perform similar functions can 
be pooled together for benchmarking purposes, and 
various accounting and cost characteristics can be 
benchmarked for the entire pool of assets. The resulting 



aggregate and average benchmark values can be com- 
pared to the promised or estimated characteristics 404 
of the asset 31 that is being considered for procurement 
purposes. Using the system 30, it may be possible for 

5 a seller or manufacturer to provide some performance 
standards/cost related warranties relating to the bench- 
marked accounting characteristics since the seller or 
manufacturer would be able to monitor the use of the 
assets 31 . The benchmarking functionality of the system 

10 30 can be a valuable procurement tool. The system 30 
can be used to generate various forms of reporting, il- 
lustrations, graphs, and analysis relating to the bench- 
marked values. 

[01 38] One of the goals that can be achieved with the 

15 benchmarking functionality is the ability to determine 
what the total cost of ownership for a particular asset 31 
is before that asset is purchased. If the asset 31 is not 
a totally new make and model, benchmarking data can 
exist for that asset 31 . Even if the asset 31 is of a totally 

20 new make and model, other assets most closely resem- 
bling the target asset 31 can be used as a proxy for the 
asset 31 under procurement considerations. The ability 
to include data from other non-related organizations is 
an important mechanism for expanding the source of 

25 data. Otherwise, a company considering the purchase 
of a particular type of asset 31 for the first time would 
have no data with which to benchmark. 
[0139] Benchmarking costs can be an important part 
of a company's budgetary process. The benchmarking 

30 functionality can be used to determine the cost of asset 
31 over various different time increments (over the life 
of the asset, per year, per month, per hour, etc). The 
data can be compiled and made available to businesses 
so that more accurate budgets can be prepared. 

35 [0140] Using the benchmarking functionality, an ana- 
lyst 400 can compare how similar assets 31 age, with 
. particular attention being paid to costs and maintenance 
work. The frequency of repairs can be predicted, as can 
total labor hours related to those repairs. All of these 

<o characteristics have important monetary implications. 
The system 30 can adjust costs and other financial data 
for inflation. The benchmark heuristic can automatically 
perform cost benchmarking relating to various time 
frames and cost categories. Reports could be generated 

45 indicating industrywide benchmark information, and ap- 
propriate goals for achieving "best practices." The 
benchmarking functionality can also be utilized with re- 
spect to operational and other characteristics of assets 
not directly relating to accounting and financial at- 

50 tributes. 

[0141] In accordance with the provisions of the patent 
statutes, the principles and modes of operation of this 
invention have been explained and illustrated in pre- 
ferred embodiments. However, it must be understood 
55 that this invention maybe practiced otherwise than as 
specifically explained and illustrated without departing 
from its spirit or scope. 
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Claims 

1 . A method for benchmarking data relating to an as- 
set, comprising the steps of: 

5 

selecting a group of assets be included in the 
pool of benchmarking information on a compu- 
ter; 

identifying on a computer an asset characteris- 
tic relating to an asset included in the pool of »o 
benchmarking information; and 
invoking a benchmark heuristic on a computer 
to generate a benchmark value relating to the 
identified asset characteristic; 

15 

wherein at least two organizations contribute 
to the pool of benchmarking information. 

2. A method for benchmarking data relating to an as- 
set as in claim 1, wherein the selected group of as- 20 
sets are selected on the basis of a shared asset 
characteristic. 

3. A method for benchmarking data relating to an as- 
set as in claim 1 , further comprising comparing the 25 
benchmark value to a characteristic of a target as- 
set. 

4. A method for benchmarking data relating to an as- 
set as in claim 1 , wherein the pool of benchmarking 30 
information and the benchmark value are stored on 

a database. 

5. A method for benchmarking data relating to an as- 
set as in claim 1 , wherein at least two non-related 35 
organizations contribute to the pool of benchmark- 
ing information^ ________ _ 

6. A method for benchmarking data relating to an as- 
set as in claim 1, wherein the benchmark value is *o 
cost information relating to the asset. 

7. A method for benchmarking data relating to an as- 
set as in claim 1 , wherein organizationally identifia- 
ble information is not accessible to a end-user. 45 

8. A method of benchmarking data relating to an asset 
as in claim 1 , wherein an end-user in one organiza- 
tion cannot view organizationally identifiable infor- 
mation belonging to a different organization. 50 

9. A system for benchmarking data relating to an as- 
set, comprising: 

a plurality of assets including an asset charac- 55 
teristic and a data value for said asset charac- 
teristic; 

a plurality of organizations with relationships to 



said plurality of assets; 

a benchmarking information pool including said 
data value for said asset characteristic for said 
plurality of assets associated with said plurality 
of organizations; and 

a benchmark heuristic to generate a bench- 
mark value for said asset characteristic from 
said benchmarking information pool. 

10. A system for benchmarking data relating to an asset 
as in claim 9, wherein said plurality of organizations 
include at least two unrelated organizations. 

1 1 . A system for benchmarking data relating to an asset 
as in claim 9, said benchmarking information pool 
including a plurality of organizationally identifiable 
data, wherein said plurality of organizationally iden- 
tifiable data is hidden from said benchmarking in- 
formation pool before the application of said bench- 
marking heuristic. 

12. A system for benchmarking data relating to an asset 
as in claim 11, wherein said plurality of organiza- 
tionally identifiable data is hidden from said plurality 
of organizations. 

13. A system for benchmarking data relating to an asset 
as in claim 9, wherein said benchmark value is a 
monetary amount. 

1 4. A system for benchmarking data relating to an asset 
as in claim 9, said plurality of assets including a first 
asset characteristic, a second asset characteristic 
and a larger plurality of assets; 

wherein said plurality of assets are a subset 
of said larger plurality of assets; 

wherein said first asset characteristic is in- 
cluded in said benchmarking information pool; and 

wherein said plurality of assets are selective 
identified from said larger plurality of assets on the 
basis of said second asset characteristic. 

1 5. A system for benchmarking data relating to an asset 
as in claim 14, wherein said second asset charac- 
teristic is not included in said benchmarking infor- 
mation pool. 

1 6. A system for benchmarking data relating to an asset 
as in claim 9, further comprising a target asset in- 
cluding said asset characteristic and a target value, 
wherein said system automatically compares said 
target value to said benchmark value. 

17. A system for benchmarking data relating to an asset 
as in claim 9, further comprising a database, where- 
in said pool of benchmarking information is stored 
on a database. 
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1 8. A system for benchmarking data relating to an asset 
as in claim 9, furth r comprising a plurality of asset 
values and a plurality of benchmark values, wherein 
said benchmark heuristic generates said plurality of 
benchmark values from said plurality of asset val- 
ues. 

19. A system for benchmarking data relating to an as- 
set, comprising: 



10 



a plurality of assets, including a subset of se- 
lected assets, wherein each asset in said plu- 
rality of assets includes a plurality of asset char- 
acteristics and wherein each said asset char- 
acteristic has a data value; is 
a plurality of organizationally identifiable data, 
including a subset of said asset characteristics 
and said data value relating to said asset char- 
acteristics; 

a plurality of unrelated organizations with rela- 20 
tionships to said plurality of assets; 
a benchmarking information pool including said 
data value for said asset characteristic for said 
plurality of assets associated with said plurality 
of organizations; and 25 
a benchmark heuristic to generate a plurality of 
benchmark values for said plurality of asset 
characteristics from said benchmarking infor- 
mation pool. 
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